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Előszó 








2011-ben újra megrendezésre került a budapesti Szabad Szoftver Konferencia 
és Kiállítás. 


A szervező FSF.hu Alapítvány legfontosabb célja a szabad szoftverek hazai 
népszerűsítése, ugyanakkor nagyon fontosnak tartjuk a hazai szabad 
szoftveres közösség együttműködését. Ennek szellemében minden olyan hazai 
civil szervezetet és céget meghívtunk kiállítónak, akik közreműködnek a 
szabad szoftverek és ahhoz köthető szellemiség építésében, népszerűsítésében. 


A konferencián számos ismert és elismert előadó tartott színvonalas szakmai 
előadásokat. Ebben az évben a korábban tisztán szakmai program kiegészült 
egy egész napos közigazgatási szekcióval, ahol a kormányzat, önkormányzatok 
és sikeres nagy projektek képviselői adtak betekintést a szabad szoftverekkel 
kapcsolatos munkájukba, sikereikbe, stratégiájukba. 


A konferencián több, mint négyszáz hallgató tekintette meg az előadásokat, 
melyekről videofelvétel is készült. 


A videókat legegyszerűbben a konferencia http://konf.fsf.hu címen található 
weboldaláról lehet elérni. 


Az előadók a bemutatóik mellé írtak egy-egy összefoglaló-, kiegészítő anyagot, 
ezeket az anyagokat gyűjtöttük össze ebbe a könyvbe. Reméljük, hasznos 
olvasmány lesz minden érdeklődő számára. 
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Előadások 


Java— mi újság a licenc fronton? 
Ádám Szilveszer 


Kivonat 


A Java platform az utóbbi évtizedben az egyik legnépszerűbb szoftverfejlesztési és -futtatási kör- 
nyezetté vált, inplementációi mára elérhetőek a legkülönfélébb hardverkörnyezetekhez és operá- 
ciós rendszerekhez, a nagy teljesítményű szerverektől az intelligens kártyákig. 

A Java platform egységének fenntartásában a mögötte álló nagyvállalatok piaci erején és el- 
kötelezettségén túl mind a szerzői jog, mind pedig az iparjogvédelem körébe tartozó védjegyjog 
szabályainak komoly szerepük volt. 

A mostani alkalommal arra vállalkozunk, hogy bemutassuk azokat a fontosabb jogi problémá- 
kat, amelyek a Java platform, kiemelten pedig a Java virtuális gép (ТУМ) és az alapvető futásidejű 
könyvtár (Java Standard Class Libraries) fejlesztői, valamint az ezeket más rendszerekkel integ- 
rálni szándékozók számára jelentkeznek. Ezt követően sorra vesszük a jelenleg (2011 őszén) jelen- 
tősebb felhasználói közösséggel rendelkező Java megvalósításokat és az ezekhez tartozó licenc- 
feltételeket, rávilágítva azokra az akadályokra is, amelyek miatt jelentős számú, részben egymást 
is átfedő célkitűzésekkel rendelkező projekt dolgozott egy időben különféle alternatív Java meg- 
valósításokon. Legvégül pedig röviden kitérünk arra is, hogy ezek a problémák hogyan nyernek 
jelentőséget a jelenleg legnépszerűbbnek számító okostelefon- és táblagépplatform, az Android 
körüli csatározásokban. 
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2 JELENTŐSEBB PROBLÉMÁK AZ ALTERNATÍV IMPLEMENTÁCIÓK SZÁMÁRA 





1. Bevezetés 


A Java platform az utóbbi évtizedben az egyik legnépszerűbb szoftverfejlesztési és -futtatási kör- 
nyezetté vált, implementációi mára elérhetőek a legkülönfélébb hardverkörnyezetekhez és operá- 
ciós rendszerekhez, a nagy teljesítményű szerverektől az intelligens kártyákig. A Java programozási 
nyelv jelenleg is dobogós helyen szerepel a legnépszerűbb programozási nyelvek rangsorában. Ez a 
siker nem kis részben annak volt köszönhető, hogy a nyelv és a platform folyamatos fejlesztése köz- 
ben sikerült kitartani az egyik legfontosabb eredeti célkitűzés mellett: az egyszer megírt szabványos 
Java kód bármilyen, a specifikációknak megfelelően működő Java futtató környezetben változtatás 
nélkül lefuttatható. 

A Java platform egységének fenntartásában a mögötte álló nagyvállalatok piaci erején és elkö- 
telezettségén túl mind a szerzői jog, mind pedig az iparjogvédelem körébe tartozó védjegyjog sza- 
bályainak komoly szerepük volt. Ugyanakkor éppen ezeknek az egységet fenntartani hivatott szabá- 
lyoknak a merevsége az évek során sok vitának is forrása volt mind a Java platform megvalósításán 
dolgozók, mind a platform használói körében, mivel – más környezetekhez képest- kevésbé tették 
lehetővé a platform mindenkori hivatalos gazdájától független implementációk készítését és terjesz- 
tését. Amikor a Sun Microsystems Inc. 2006-ban bejelentette, hogy a Java platform általa készített 
referenciaimplementációját nyílt forrásúvá teszi, úgy tűnhetett sokak számára, hogy végre komoly 
elmozdulás történik ezen a területen is. Amikor pedig a Sun azt is bejelentette, hogy a Java plat- 
form következő nagy verzióváltása után már a fejlesztés alapját is egységesen a szabad szoftverként 
elérhető kódbázis fogja képezni, a korábbi viták végképpen lezárhatónak tűntek. 

Ma, a nevezetes bejelentés után öt évvel azonban azt láthatjuk, hogy bár a Java platform és prog- 
ramozási nyelv népszerűsége töretlenül növekedett, az ide tartozó technológiákra vonatkozó szoft- 
ver licencelési feltételek és a kapcsolódó védjegyek használatával kapcsolatos előírások továbbra 
is megválaszolandó kérdéseket vetnek fel a mindennapi gyakorlatban. Sőt, ezek mellett mostanra 
az informatikai ipar egészéhez hasonlóan itt is egyre nagyobb a szerepe a szabadalmaknak is, ame- 
lyek — elsősorban a velük rendelkezők szándékainak kiszámíthatatlansága és az érvényesíthetőségük- 
kel kapcsolatos bizonytalanságok miatt — a független megvalósításoknak további gátját jelenthetik. 

A mostani alkalommal arra vállalkozunk, hogy bemutassuk azokat a fontosabb jogi problémá- 
kat, amelyek a Java platform, kiemelten pedig a Java virtuális gép (JVM) és az alapvető futásidejű 
könyvtár (Java Standard Class Libraries) fejlesztői, valamint az ezeket más rendszerekkel integrálni 
szándékozók számára jelentkeznek. Ezt követően sorra vesszük a jelenleg (2011 őszén) jelentősebb 
felhasználói közösséggel rendelkező Java megvalósításokat és az ezekhez tartozó licencfeltételeket, 
rávilágítva azokra az akadályokra is, amelyek miatt jelentős számú, részben egymást is átfedő célki- 
tűzésekkel rendelkező projekt dolgozott egy időben különféle alternatív Java megvalósításokon. Leg- 
végül pedig röviden kitérünk arra is, hogy ezek a problémák hogyan nyernek jelentőséget a jelenleg 
legnépszerűbbnek számító okostelefon- és táblagépplatform, az Android körüli csatározásokban. 


2. Jelentősebb problémák az alternatív implementációk számára 


A Java platform kifejlesztésekor a kezdeményező szerepet betöltő Sun Microsystems egy olyan öko- 
szisztémát akart létrehozni, amely egyrészről kellően nagy szabadságot ad a mellette döntő fejlesz- 
tőknek arra, hogy a Sun referenciaimplementációja mellett potenciálisan több szereplő által felkínált 
versenyző megoldásokból választhassanak, másrészről azonban meg akarta akadályozni az egységes 
Java platform feldarabolását egymással nem, vagy csak részben kompatibilis konkurens megoldások 
révén. Ez a törekvés érthető is volt az előző évtizedekben a kereskedelmi UNIX típusú rendszerek 
körében végbement fejlemények tükrében, ahol az egyes cégek által kínált UNIX variánsok közötti 


növekvő inkompatibilitás végül az egész platformot gyengítette meg, és ilyen módon egy külső ver- 





senytárs, a Microsoft megerősödését segítette elő. Ezért, bár a Sun idővel egyre jobban megnyitotta 
a Java platform további fejlesztését tőle független szereplők előtt is, akik a Java Community Process 
révén az irányadó specifikációk kidolgozásának aktív részesei lehettek, de a különféle licencelési 
szabályok és a kezében lévő védjegyek használatának korlátozása segítségével mindig gondosko- 
dott arról, hogy egy-egy implementáció megfelelőségéről maga mondhassa ki a végső szót. Ezen a 
téren a legjelentősebb akadályt az jelentette és jelenti a potenciális versenytársak előtt, hogy a "Java" 
megnevezést és a kapcsolódó védjegyeket csak azok az implementációk használhatják, amelyek si- 
kerrel teljesítették az adott specifikációhoz tartozó Technology Compatibility Kit (TCK) tesztjeit. 
Ugyanakkor már a TCK-hoz való hozzáférés sem volt mindenki számára nyitott, így különösen a 
szabad szoftver projektek számára jelentett komoly problémát a megfelelőségi tesztelés. Mint látni 
fogjuk, azóta ezen a téren voltak változások, de még mindig nem beszélhetünk egyenlő hozzáférési 
lehetőségről minden projekt számára. A TCK tesztek sikeres teljesítése mellett további feltétel, hogy 
az érintett fejlesztő, vagy csoport megállapodjon a védjegyek használatáról a jogosulttal ( Sun, majd 
Oracle). Mivel ilyen megállapodást nem mindenkinek sikerült tető alá hoznia, ma is nem egy pro- 
jektet találunk, amelynek kínosan kerülnie kell még a "Java" szó használatát is a saját termékével 
kapcsolatban, ami viszont megnehezíti az alkalmazásfejlesztők közösségében a szükséges ismertség 
és bizalom megszerzését. 


A forráskód megnyitása előtt csak nagyon kevés valóban használható alternatív megvalósítás 
létezett, ezek fejlesztésének nehézsége miatt a gyakorlatban a legtöbb esetben a Sun által készített 
referenciaimplementációkat (Java Runtime Environment— JRE, Java Development Kit—JDK) hasz- 
nálták. Ezek— bár a legtöbb esetben ingyenesen beszerezhetők voltak – zárt forrású kereskedelmi 
termékek voltak, amelyeknek a terjesztését is csak meghatározott feltételek teljesítése mellett enge- 
délyezte a Sun. További problémát jelentett, hogy a Sun a JRE-t és a JDK-t is csak a saját megíté- 
lése szerint jelentősebb hardverarchitektúrákra és operációsrendszer-környezetekre készítette el, így 
például a Mac OS és a Linux hosszú ideig nem rendelkezett támogatással. Ezért a Java platform 
történetében valóban nagy jelentősége volt a Sun azon döntésének, hogy a Java környezet alapvető 
alkotóelemeit, így mindenekelőtt a JVM-et és az alapvető futásidejű könyvtárat nyílt forrásúvá teszi, 
kivéve azokat a komponenseket, amelyek harmadik féltől származó kódot tartalmaztak. Középtávon 
azonban itt is az volt a cél, hogy ezeket szintén megnyissák, vagy azonos funkcionalitású szabad 
szoftveres licencű komponensekkel helyettesítsék. A bejelentést követő fél év alatt a továbbra is 
zártan maradó komponensek arányát 5% alá csökkentették mind az aktuálisan termékként a piacon 
elérhető, mind pedig a következő jelentős verzióugrást jelentő 1.6-os verzió alapját adó kódbázis 
esetében, a későbbiekben pedig sikerült ezeket lényegében eliminálni. (A zárt licencű komponense- 
ket a Sun továbbra is használta a saját, csak bináris formában terjesztett JRE és JDK kiadásaihoz) A 
Java platform soron következő verziójának (Java 7) fejlesztése pedig már eleve legnagyobb részben 
a forráskód megnyitása után zajlott, így ott az ezzel kapcsolatos követelményeket is időben figye- 
lembe lehetett venni. Ettől függetlenül az alternatív inplementációk fejlesztése nem lett feltétlenül 
könnyebb, mint azt a következőkben látni is fogjuk. 


3.  Leltárfelvétel— a legnépszerűbb Java implementációk 


Ebben a fejezetben sorra vesszük a jelenleg használt legelterjedtebb Java megvalósításokat a rájuk 
vonatkozó licencfeltételekkel együtt, ideértve a zárt forrású programokat és a szabad szoftveres pro- 
jekteket is. 


3 LELTÁRFELVÉTEL – А LEGNÉPSZERŰBB JAVA IMPLEMENTÁCIÓK 





3.1. Oracle JRE/JDK 


A forráskód 2006-2007-ben végbement megnyitását követően a Sun, majd a céget és vele együtt 
a Java platformhoz kötődő technológiákat és jogosultságokat is felvásárló Oracle Corporation is 
folytatta a bináris formában elérhetővé tett, zárt forrású referenciaimplementáció megjelentetését. 
Jelenleg a JDK és a JRE Solaris, Windows és Linux környezetekre érhető el 32 és 64 bites x86 
architektúrákra. Az ingyenesen, az Oracle honlapjáról letölthető alapszintű JDK mellett a cég kínál 
további, többletfunkciókat is tartalmazó verziókat is díjfizetés ellenében (Java SE Advanced, Java SE 
Suite). A JVM és az alapvető futásidejű könyvtár mellett mindhárom verzió tartalmazza a Java app- 
letek megjelenítéséhez szükséges böngészőbővítményt, valamint a weben elérhető Java programok 
előzetes telepítés nélküli futtatását lehetővé tevő Java Web Start (JWS) összetevőt is. Noha a később 
bemutatandó nyílt forrású OpenJDK projekten alapulnak, mind futtatásuk, mind pedig a szoftver 
beszerzése, példányainak többszörözése és terjesztése csak korlátozottan, az "Oracle Binary Code 
License Agreement" által meghatározott körben és feltételekkel megengedett. Ez a gyakorlatban azt 
jelenti, hogy amíg az egyes felhasználók saját céljaikra letölthetik, többszörözhetik, telepíthetik és 
használhatják ezeket, a terjesztés változatlan formában 15 már csak akkor megengedett, ha az egy 
olyan saját program mellé csomagoltan történik, amelynek futtatásához a JRE (és esetleg a JDK 
Oracle által külön meghatározott részei) szükséges, és amely jelentős többletértéket jelentő funkció- 
kat tartalmaz a JRE-hez képest. Külön is tiltott a terjesztés bármilyen olyan más szoftverrel együtt, 
amelynek célja az Oracle által biztosított JRE bármely részének lecserélése, illetve kiváltása. 

Ez a gyakorlatban azt jelenti, hogy ezt a JRE-t/JDK-t például fő szabály szerint nem lehet egy 
operációs rendszer környezettel együtt terjeszteni, mert ott a fentebb írt feltételek nem teljesülnek. 
(Érdekes megjegyezni, hogy kimondottan a különféle Linux terjesztésekbe való integrálás lehetővé 
tétele érdekében korábban létezett egy "Operating System Distributor License for Java" is, de ezt az 
Oracle 2011. augusztus 29-cel visszavonta.) 


3.2. OpenJDK 


Az OpenJDK projekt azoknak a forráskódelemeknek a bázisán jött létre, amelyeket a Sun 2006-tól 
kezdve adott közre szabad szoftverként. Legelőször a HotSpot nevű virtuális gép került kiadásra, 
majd 2007-ben a teljes alapvető futásidejű könyvtár (Java Standard Class Library), kivéve azokat 
az elemeket (így például a grafikus felület egy részét), amelyeket a Sun-nak harmadik személyek 
fennálló jogai miatt nem volt lehetősége nyílt forrásúvá tenni. Ezeknek aránya kezdetben 4% volt 
a teljes könyvtárkódból, később azonban a hiányzó részek mindegyikét vagy kiadták a szükséges 
engedélyek beszerzése után, vagy pótolták más, azonos funkciójú, de szabadon kiadható részek- 
kel. A JDK részét képező parancssoros eszközök, pl. a javac nevű fordítóprogram szintén szabad 
szoftverként kerültek közreadásra. Nem adták ki viszont a böngészőbővítményt és a Java Web Start 
programot sem, noha a Sun ezt többször is megígérte az idők folyamán. Ма az OpenJDK projekt két 
fő ággal rendelkezik, az egyik (OpenJDK6) a Java platform 1. 6-os verzióját követi, a másik pedig 
(OpenJDK) a 7.0-s verziót. A korábban írtaknak megfelelően a Java 7.0 referenciaimplementációja 
már egyértelműen az OpenJDK alapján készült. (A Java 1.6 esetében a helyzet annyiban volt más, 
hogy ott a forráskód publikálása már az első általános felhasználásra szánt kiadás elkészítése utáni 
időre esett, így az OpenJDK6 projekt kódbázisa nem teljesen azonos a Sun, majd később az Oracle 
által továbbfejlesztett 1.6 referenciamegvalósítás egyes verzióihoz publikált forráskódcsomagokkal, 
amelyeknek a licencfeltételei is mások.) 

A Sun a szabad szoftverként kiadott JDK és JRE licencelésére a GNU General Public License 
második verzióját (GPLv2) választotta az úgynevezett kapcsolási kivétellel (linking exception). Ez 
azt jelenti, hogy — ellentétben a GPL általános szabályával, amely szerint bármely, a GPL alatt ki- 
adott program, vagy programrész bármely módosított változata, vagy azon alapuló származékos mű 
éppen úgy a GPL hatálya alá kerül, mint bármely olyan mű is, amivel a GPL alatt álló programot, 
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3.3 IcedTea 





vagy programrészt (például egy könyvtárat) dinamikusan, vagy statikusan kapcsolják (dynamic, il- 
letve static linking) – 1 a GPL alatt álló művet bármilyen más nyílt, vagy nem nyílt forrású licenc 
alatt kiadott más programhoz lehet kapcsolni, feltéve, hogy az új program nem a GPL alatt álló prog- 
ram, vagy programrész módosításával keletkezett származékos mű. Ezzel a megoldással kívánta a 
Sun biztosítani, hogy az általa kiadott JDK és JRE forrásokból készített binárisokkal továbbra is 
lehessen nem szabad szoftverként kiadott Java kódot is fordítani, értelmezni és futtatni. (Hasonló 
megoldást alkalmazott a Free Software Foundation is a GNU Compiler Collection — GCC esetében, 
hogy lehetővé tegyék a GCC felhasználását nem szabad szoftverek fordítására is.) 

Fontos kiemelni, hogy sem az eredeti, Sun által kiadott forráskódot, sem pedig az OpenJDK 
projektek kódját nem lehet pusztán a szokásos, fejlesztői munkaállomásokon általában meglévő esz- 
közökkel lefordítani, hanem ehhez további binárisokra van szükség, ezeket külön tették elérhetővé 
más licencfeltételek alapján. Emellett az OpenJDK projekt keretében csak forráskód közzétételére 
kerül sor, kész, bináris formában elérhető JDK, illetve JRE nem tölthető le. Ehelyett a felhasználókra 
vár a feladat, hogy a forráskód, a külön letöltött binárisok és a közzétett utasítások alapján a binári- 
sokat létrehozzák. Mivel ezeket így nem a Sun, illetve az Oracle hozza létre, ezért nem is mennek át 
tesztelésen abból a szempontból, hogy megfelelnek-e az aktuális specifikációknak. Viszont az ered- 
mény csak akkor tekinthető Java kompatibilisnek, ha ezek a tesztelések eredményesen lezajlottak. 
Annak érdekében, hogy az OpenJDK felhasználóknak megkönnyítsék a megfelelőség tesztelését, a 
Sun, majd az Oracle számukra hozzáférhetővé tette a Technology Compatibility Kitet (TCK) egy 
speciális licenc alapján, amely kimondottan csak az OpenJDK és az annak felhasználásával készült 
projektek megfelelőségének ellenőrzésére engedélyezi a használatot. (OpenJDK Community TCK 
License Agreement- OCTLA). Természetesen ha valaki a Java nevet, logót, vagy más, kapcsolódó 
védjegyet is használni kívánja az általa készített binárisokra, akkor arra külön kell védjegyhasználati 
megállapodást kötnie az Oracle Inc-vel. 

Az OpenJDK projekt a fentebb jelzett specialitásai ellenére 15 gyorsan népszerű lett, a különféle 
Linux terjesztések számára készült kész csomagok (gyakran a hivatalos, Sun, illetve Oracle által 
kiadott JDK/JRE mellett), valamint a Windows és a Linux mellett több más operációs rendszer 
platformon is működő változatok állnak rendelkezésre (így például FreeBSD-re, vagy MacOS Х- 
re.) 


3.3. IcedTea 


Az IcedTea projektet az az igény hívta életre, hogy az OpenJDK projekt keretében kiadott forrás- 
kódot olyan Linux terjesztéseknél is fel lehessen használni csomagok készítésére, amelyek nem 
engedik a zárt forrású eszközök használatát erre a célra. (Ilyen például a Fedora projekt.) Emel- 
lett céljai között szerepelt az OpenJDK projektben hiányzó böngészőbővítmény és Java Web Start 
komponensek nyílt forrású helyettesítőinek kifejlesztése is (IcedTea-Web projekt). Elnevezését azért 
kapta, mert a Java védjegy használatára nem rendelkeztek engedéllyel a fejlesztők. Mivel a céljai kö- 
zött szerepel, hogy az itt már kipróbált és megfelelőnek bizonyult változtatások idővel bekerüljenek 
az OpenJDK forrásfájába is, ezért azzal azonos licencelési szabályokat használnak (GPLv2 + kap- 
csolási kivétel). Az IcedTea projekt eredményeképpen lehetségessé vált az, hogy az OpenJDK forrá- 
sokat kizárólagosan szabad szoftverek felhasználásával lefordíthassa egy fejlesztő. Emellett jelenleg 
csak ennek a projektnek a keretében érhető el olyan böngészőbővítmény, amely natívan támogatja a 
64 bites böngészőket. 


3.4. Apache Harmony 


A Harmony projekt célja egy, a Sun-tól független, nyílt forrású Java implementáció létrehozása, kez- 
detei pedig még régebbre nyúlnak vissza, mint az OpenJDK fejlesztéseké. Eredetileg a Java platform 
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3 LELTÁRFELVÉTEL – А LEGNÉPSZERŰBB JAVA IMPLEMENTÁCIÓK 





1.5-ös verziójának megfelelő JDK közreadása volt a cél, de később megkezdték az 1.6-os verzió spe- 
cifikációjának megvalósítását is. A projekt licencelési okokból először teljesen nulláról kezdett, de 
szívesen fogadott hozzájárulásokat egyéni fejlesztőktől és cégektől is, így az első években viszony- 
lag gyorsan fejlődött. Mint az Apache Software Foundation hivatalos projektjei, a Harmony is az 
Apache License használata mellett döntött. Ez egy megengedő típusú szabadszoftverlicenc, mivel 
alapvetően nem korlátozza, hogy az alá tartozó programokat vagy progrankomponenseket milyen 
célra lehet használni, és nem állít korlátokat a módosítások, valamint a módosított változatok terjesz- 
tése elé sem. Csupán azt kívánja meg, hogy a módosítások legyenek megjelölve, valamint az ere- 
deti szerzőkkel és szerzői jogokkal kapcsolatos jelölések maradjanak épségben. Emellett az Apache 
License 2.0-ás verziója már előírja azt is, hogy amennyiben egy módosítás használatához szükség- 
szerűen olyan szabadalmak használata is szükséges, amelyeknek a módosítás szerzője a jogosultja, 
akkor a módosított verzió használója automatikusan engedélyt kap ezeknek a szabadalmaknak a 
használatára is. 


Bár a Harmony projektnek hangsúlyozottan célja volt az is, hogy a különböző Java implementá- 
ciókon dolgozó fejlesztők és fejlesztői csoportok együttműködését és közös munkáját elősegítse, a 
licencfeltételek különbözősége ezt a gyakorlatban eléggé megnehezítette. Mivel az Apache License 
és a GPLv2 egymással nem összeegyeztethető szabályokat tartalmaz, (a GPLv2 semmilyen olyan 
licenccel nem kompatibilis, amelyik hozzá képest többlet korlátozásokat ír elő) a Harmony projekt 
nem használhatta fel a többi, ebben a fejezetben bemutatott szabadszoftver-kezdeményezés kereté- 
ben írt és szabadon elérhető kódot, és fordítva sem volt ez lehetséges. A GPL 2007-ben elfogadott 
legújabb, harmadik verziója (GPLv3) az Apache License 2.0-s verzióját már kompatibilisnek ismeri 
el, de ez csak azokra a programokra, vagy programkomponensekre hathat ki, amelyeket már eleve 
ilyen licenc alatt adtak ki, vagy legalább a feltételek lehetővé teszik ugyanazon licenc későbbi verzi- 
ójának használatát is. (Sok GPLv2 alatt kiadott program esetén ez a lehetőség adott.) További prob- 
lémát jelentett, hogy a Harmony projektnek nem sikerült a TCK használatára olyan feltételek mellett 
engedélyt kapnia, amely az Apache License feltételeinek megfelelően minden fejlesztő előtt nyitva 
állt volna, közvetlen felhasználási célra vonatkozó megkötés nélkül. Ezért az általuk készített JDK 
és JRE binárisok Java specifikációknak való megfelelőségét nem lehetett az előírt tesztek teljesítésé- 
vel bizonyítani, ami az OpenJDK-val és a rá épülő projektekkel szemben jelentős hátrányt jelentett. 
Mára a Harmony projekt több jelentős támogató távozását követően gyakorlatilag felfüggesztődött. 


3.5. GNU Compiler for the Java programming language (gcj) 


A Free Software Foundation (FSF) égisze alatt működő gcj projekt egy olyan fordítóprogramot 
fejlesztett ki, amely képes a Java forráskódot mind a szokásos JVM-ek által végrehajtható biná- 
ris kóddá (class fájlok) mind pedig a CPU által közvetlenül végrehajtható natív alkalmazáskóddá 
átalakítani. Része a különféle programnyelvekhez fordítóprogramokat tartalmazó GCC-nek (GNU 
Compiler Collection). A gcj önmagában nem volt alkalmazható, mivel a programok lefordításához 
egyéb komponensek (mindenekelőtt az alapvető futásidejű könyvtár— Java Standard Class Library) 
is szükségesek voltak. Ezért a gcj projekt szorosan együttműködött a később bemutatandó GNU 
Classpath fejlesztőivel, azt is célul tűzték ki, hogy a libgcj nevű futásidejű könyvtárat összevezetik a 
másik megvalósítással a gyorsabb előrehaladás érdekében. А gcj— a ССС többi tagjához hasonlóan — 
a GPLv2, illetve GPLv3 licenc alatt érhető el, a kapcsolási kivétel itt is szerepel annak érdekében, 
hogy nem szabad szoftvernek minősülő programkód lefordításához is lehessen használni. Bár а ес] 
jelenleg is része minden GCC kiadásnak, jelentős fejlesztésekre az utóbbi időben már nem került 
SOT. 
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3.6 GNU Classpath projekt 





3.6. GNU Classpath projekt 


Az ugyancsak az FSF támogatásával létrejött GNU Classpath projekt azt tűzte ki célul, hogy egy sza- 
bad szoftverként elérhető alapvető futásidejű könyvtárat fog kifejleszteni, amely a Sun által kiadott 
referenciaimplementáció helyett is alkalmazható lesz. A gyakorlatban több, szabad szoftverként elér- 
hető JVM- megvalósítás is a GNU Classpath kódját használja a saját futásidejű könyvtárának fejlesz- 
téséhez, vagy teljesen át is veszi azt. Különösen szoros együttműködés alakult ki az előbb bemutatott 
gcj projekttel, de olyan, ma már kevésbé széles körben használt szabad JVM projektek is a haszná- 
lók között vannak, mint a SableVM vagy a Kaffe. Az IcedTea projekt is alkalmazott innen származó 
programrészeket a Sun által kiadott alapvető futásidejű könyvtár hiányzó moduljainak helyén addig, 
amíg azok kiváltása, vagy megnyitása meg nem történt. A projekt keretében jelenleg már inkább 
csak hibajavítási tevékenység zajlik. A GNU Classpath projekt is a gcj-vel azonos licenc alatt érhető 
el. 


4. Mi köze ennek az Androidhoz? 


Az Android egy elsősorban hordozható eszközökön használt operációs rendszer, amelyet a Google 
által vezetett Open Handset Alliance fejleszt, miután az eredeti fejlesztőt (Android Inc.) a Google 
2005-ben felvásárolta. Az Android rendszerben a felhasználói programok egy virtuális gépben fut- 
nak (Dalvik virtual machine), amely elszigeteli őket egymástól és az operációs rendszertől. A fejlesz- 
tők által a Java programozási nyelv egy dialektusában írt programkódot a készülékre telepítés előtt 
átalakítják előbb bináris Java kóddá (class fájlok) , majd ebből hozzák létre a Dalvik Executable 
(.dex) fájlokat, amelyeket a Dalvik virtuális gép értelmezni tud. Bár a Dalvik nem tekinthető teljes 
JVM megvalósításnak, az alapvető futásidejű könyvtár egy jelentős részét implementálja, ehhez az 
Apache Harmony projekt által közzétett kódot is felhasználja. A Dalvik — az Android rendszer 2.3.x 
és előző verzióiban legalábbis – а> Apache License alatt nyílt forrású szoftverként érhető el. Az en- 
nél újabb verziók nyilvánosságra hozatalára a Google ígéretet tett ugyan, de erre eddig nem került 
sor. 

Az elmúlt évben az Oracle az Egyesült Államokban pert indított a Google ellen, mivel állítása 
szerint a Dalvik implementálása során a Google megsértette a Sun szerzői jogait, illetve több olyan 
szabadalmat is jogosulatlanul használt fel, amelyeknek a Sun volt a jogosultja. A Google tagadta a 
felhozott állításokat, kiemelve, hogy a Dalvik fejlesztése során nem használta fel a Sun által hozzá- 
férhetővé tett forráskódot, hanem saját, új megvalósítást készített, így nem kellett figyelembe vennie 
a Sun által publikált forráskóddal kapcsolatban fennálló korlátozásokat. Az Oracle állítása szerint 
ugyanakkor az Android fejlesztése során a felek tárgyalásokat is folytattak a kérdéses szabadalmak 
és szerzői jogilag védett programrészek használatáról, amelyek azonban akkor eredménytelenül zá- 
rultak, így azok létezéséről és mibenlétéről a Google-nek tudomása volt. 

Az Oracle által állított szerzői jogi jogsértéssel kapcsolatban konkrétumok még nem ismertek 
jelenleg, ezért a konkrét ügyről nehéz véleményt mondani. Ugyanakkor tény, hogy amennyiben va- 
lamely fejlesztő olyan programrészeket használ fel, amelyeket a Sun, vagy az Oracle a GPL alatt 
tett közzé, vagy ilyen programrészeket felhasználva hozott létre származékos műveket, akkor ezek- 
kel kapcsolatban köteles betartani a GPL terjesztéssel kapcsolatos előírásait, amelyek megkövetelik, 
hogy a binárisok mellett az azokhoz tartozó forráskódot is át kell adni, illetve elérhetővé kell tenni. 
Emellett figyelmet érdemel a GPLv3 azon előírása is, mely szerint amennyiben a GPL alatt nyil- 
vánosságra hozott kódot valamely berendezésen telepítve terjesztik, akkor a forráskód mellett át 
kell adni azokat az információkat, illetve eszközöket is, amelyek ahhoz szükségesek, hogy egy mó- 
dosítást követően a programot a berendezésen ismételten telepíteni lehessen. Itt pedig nem csak a 
Google-nek az a döntése vet fel kérdéseket, amely szerint az Android 3.0-val kezdődő verzióinak 
teljes forráskódját egy általa meghatározott későbbi időpontig nem hozza nyilvánosságra, hanem az 
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4 MI KÖZE ENNEK AZ ANDROIDHOZ? 





Androidot használó okostelefonok és táblagépek gyártóinak az a gyakorlata is, hogy az eszközön 
műszaki intézkedésekkel megakadályozzák tőlük független forrásból származó programok, minde- 
nekelőtt operációs rendszer telepítését. Ez azonban már nem csak a Java platformmal kapcsolatos 
ügy, hiszen az Android fejlesztése során számos más nyílt forrású szoftverprojekt által készített prog- 
ramot, illetve programrészt használtak fel. 

Mint az ilyen természetű eljárásokban általában, itt is várható, hogy a felek a köztük fennálló 
vitát idővel bíróságon kívül, egyezséggel fogják lezárni, azonban ennek időpontja még nem látható 
előre. Így valószínűleg hosszabb eljárásra lehet felkészülni, amely bizonytalanságot okozhat az And- 
roidot, illetve Androidra fejlesztők körében, ugyanakkor újabb adalékot szolgáltathat a szabad szoft- 
ver licencek értelmezésével kapcsolatos gyakorlathoz. 
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1 GEOGEBRA 





1. GeoGebra 


A GeoGebra! egy interaktív matematikai program, mely összefűzi a geometriát, algebrát, táblázato- 
kat, gráfokat, statisztikát és kalkulust egy könnyedén használható és felhasználóbarát programban. 
Teljesen dinamikus, interaktív, az általános iskoláktól az egyetemekig mindenhol használható. Fel- 
használóbázisa hatalmas, több mint 50 nyelvre létezik fordítás, valamint elérhetőek szerkesztések az 
interneten a http://www.geogebratube.org oldalon, a GeoGebrával készített dinamikus példák olyan 
adatbázisában, melyet a közösség tart fenn. Ez az adatbázis kereshető, szerkeszthető, azonnal kipró- 
bálható példák sokaságát tartalmazza. 

A szoftvert 2001-ben kezdte el fejleszteni szakdolgozati munkájaként Markus Hohenwarter, a 
Salzburgi Egyetem matematika szakos hallgatója (immáron a Linzi Egyetem matematikai didakti- 
kai tanszékének vezető professzora). A Javában írt, platformfüggetlen, GNU GPL 3 alapú oktatási 
szoftver 2002 óta számos díjat, elismerést nyert (többek között European Academic Software Award 
2002, Lernie Award 2005, AECT Award 2008, The Tech Awards 2009). 

A szoftvert jelenleg 200 országban használják. Havonta 300 000 letöltés és 750 000 különböző 
látogató jellemzi a program elterjedtségét. 2008 óta a megrendezésre került 29 nemzetközi Geo- 
Gebra konferencián a világ több mint 50 országából számos fejlesztő, oktató és kutató szakember 
találkozott. A Nemzetközi GeoGebra Intézet égisze alatt 57 országban 75 GeoGebra intézet ad regio- 
nális támogatást a felhasználók számára, akiket már 30 megjelent kiadvány is segít, valamint 15 000 
online elérhető tanítási segédlet és példa áll rendelkezésükre. 


1.1. A GeoGebra hazánkban 


Mielőtt a szakmai részbe keményen belevágnánk, pár szóban hadd említsem meg, hogy mi magya- 
rok hol helyezkedünk el a GeoGebra világában. Ezúton szeretnék köszönetet mondani Papp-Varga 
Zsuzsannának, aki a magyar közösség egyik vezéralakja, és az itt következő információkat rendelke- 
zésemre bocsájtotta. 

Ha a http://www.geogebra.org/ látogatottsági statisztikáira pillantunk, láthatjuk, hogy Magyar- 
országról kb. 4600 fős látogatottsággal a 28. helyen vagyunk (legelöl Franciaország 184 000 fővel). 
Az egyedi látogatók száma havonta több száztól több ezerig terjedhet, iskolai szünetekben termé- 
szetesen kis visszaesés érzékelhető. A magyarországi fő tevékenységek: előadások, workshopok, 
fordítási munkálatok, magyar nyelvű segédanyagok készítése, módszertani kutatások, pályázatok, 
és nem utolsósorban a szoftverfejlesztés, mellyel ezen értekezés fő része fog foglalkozni. 

A GeoGebra oktatása, matematika tanárok felkészítése előadások és workshopok formájában az 
egyetemeken tanárképzés keretében (ELTE, SZTE, ЕКЕ, МҮЕ), konferenciákon és továbbképzések 
alkalmával is történik hazánkban. Diplomamunkák, segédanyagok születnek folyamatosan, melynek 
nagy része elérhető a magyar wikin?. 

Kiemelten említeném az FSF.hu Alapítvány által kiírt pályázatokat, melyek segítségével a szoft- 
verfejlesztés és a közösség működése is szponzorálásra került és kerül. Az „Егу GeoGebrás Órám" 
pályázat, valamint a szoftverfejlesztés is sokat köszönhet az FSF.hu Alapítványtól kapott pályázati 
támogatásnak. 

A kicsiny országunk polgárai a közösségi oldalakon (Facebook, iwiw, Google csoportok és a 
GeoGebra fórum) is aktív GeoGebra résztvevők. GeoGebra intézetek alakultak Miskolcon és a Ka- 
posvárott, folyamatban van Pécsett, Szegeden és Budapesten. Az intézetekről (nemzetközi szinten) 
itt találhatunk információt: http : / /www . geogebra.org/cms/institutes. Ez egyben rá- 
látást enged, mennyire világméretű is a projekt. А http: / /www . geogebra.org/cms/team 
oldalon pedig bemutatjuk, kik is vagyunk mi pontosan. 





lhttp://www.geogebra.org/ 
http: //www.geogebra.org/en/wiki/index.php/Hungarian 
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1.2. A GeoGebra felépítése 


Kedves olvasó, ha idáig eljutottál, vége a száraz bevezetőnek, kezdődhet az izgalmas szakmai rész! 
На a Java, Ant, autobuild, Eclipse, НТМІ 5, JavaScript, CSS, GWT, Git, буп szavak vagy ezek bár- 
milyen kombinációja számodra , zavart kelt az Erőben", javaslom, helyezkedj el kényelmesen. Mivel 
most egy több mint tíz éve folyamatosan fejlődő projektről fogok beszélni, amely igen szerteágazó, 
néhány dolgot csak részlegesen érintek, másokról többet beszélek. Bármilyen kérdés merülne fel 
benned, ne hezitálj emailt dobni a gabor @ geogebra.org címre. 


A GeoGebra egy Java nyelven íródott projekt, fejlesztése Eclipse-ben zajlik. (Én megszállott 
Vim rajongó vagyok. Egyszer hackeltem Javát Vim-ben. . . nem akarok beszélni róla). Két plugin, 
a JavaCC parser, valamint a Subversive Svn verziókezelő szükséges az alap Eclipse-en kívül. A 
megjelenítés Swing GUI-val történik. Hogy gyors elképzelésünk legyen a kinézetről, íme egy kép: 
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2GraphicsViewsDemo.ggb 
Fájl Szerkesztés Nézet Munkaasztalok Веёйазок Eszküzük Ablak Súgó 
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к Ы enubar 13365 | class geogebra. eucUidian. Euclidianview 
йй geogebra.gui.menubar 13365 (vs Message from [geogebra. gui .menubar .GeoGebraMenuBar .updateNenubar] 
» р geogebra.gui.toolbar 13382 ыта шш 


* нї geogebra.gui.toolbar images 1 


9 Signinto Google... | г* geogebra 


A program kezdetektől fogva működik applet verzióval is, mely HTML oldalakba ágyazott Java 
appletekkel éri el (szinte) azt a funkcionalitást, melyet a desktop verzió. Ez nagyon kézenfekvő 
módja a szerkesztések bemutatásának, megosztásának, főleg mióta a geogebratube.org élesben fut, 
mely gyakorlatilag csak erre a funkcióra hagyatkozik, és szervesen össze van kötve a desktop ver- 
zióval (azaz van Share gombunk, mellyel egy kattintással megoszthatunk a geogebratube-ra). És itt 
jön a nagy bumm, de ne rohanjunk előre. 


A fejlesztés Svn (Subversion) verziókövetővel zajlik. A kb. 30 fejlesztő a világ minden tájáról 
egy SVN-repositoryba? küldi fel a fejlesztett kódot. A kód menedzselése, ticketek kezelése, külön- 
féle dokumentációk fenntartása trac! rendszerrel működik. Ez mind szép és jó, megszokott, összeállt 
rendszer. Tökéletes. Szeretjük. És ekkor. . . 





http: //www . geogebra . org/svn/trunk/geogebra/ 
"http: //www.geogebra.org/trac 
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2. GeoGebraMobile 


„Apple hates Flash”. Arról sajnos már említés sem esik, hogy „Apple hates Java, too”. Pedig bizony. 
Hogy konkrétak legyünk, az esélye annak, hogy a GeoGebra (vagy egyéb Java- Swing alkalmazás) 
futni fog mobil (iPad, iPhone, Android stb.) eszközökön, erősen konvergál a zéróhoz. Ez pedig elég 
kellemetlen olyan program esetében, melynek lényege épp a webes megoszthatóság. 

Szerencsére Markusnak 2009 szeptemberében eszébe ötlött, hogy jó lenne valamit kezdeni ezzel 
a ténnyel. Ebben az időben kezdődött el az Android telefonok elterjedése, és az iPad 2010 áprilisá- 
ban nyitott. Így hát jó barátom és munkatársam, Kovács Zoltán továbbította nekem Markus levelét, 
melyben több projekt között támogatást nyert a „GeoGebra JavaScript Port", mely később a Geo- 
GebraMobile nevet kapta. Jómagam akkor már több éve foglalkoztam JavaScript programozással, 
és rábólintottam, hogy vállalom. 


2.1. A probléma 


Az szerettük volna elérni, hogy a .ggb kiterjesztésű fájlokat valamilyen úton-módon elérhetővé, ki- 
próbálhatóvá tegyük mobil eszközökön is. A .ggb fájlok gyarkolatilag zip fájlok, egy xml-t tartalmaz- 
nak, mely maga a szerkesztés parse-olható leírása, valamint egy képet a szerkesztésről. Két lehetőség 
közül választhattunk: 


1. Egy létező rendszer használata. Nem meglepő, hogy van olyan dinamikus matematikai rend- 
szer, mely а böngészőket célozta meg platformként: ez а JSXGraphř. Egy JavaScriptben írt 
rendszer, mely egyéb matematikai szoftverek között a GeoGebra fájlokat is képes kezelni és 
megjeleníteni. A <canvas> és <svg> elemeket használja (böngészőtől függően), és egy egy- 
szerű API-t ad, mellyel dolgozhatunk: gyakorlatilag matematikai szkriptnyelvet kapunk általa. 
Mindenkinek ajánlom, aki bármilyen vizuális 2D-s alakzatos képmanipulálós webes feladat- 
hoz nem akar nulláról indulni. Tehát ezzel a rendszerrel történt pár próbálkozás az első hóna- 
pokban, mely rávilágított arra, hogy mégsem jó ötlet. Ugyanis egy létező rendszer esetén a 
következő problémákkal kell szembenéznünk: 


e Különbözik mind arculatában, mind használatában, és egyes funkciók támogatása is hi- 
ányzik. 
e Mások a rajzoló algoritmusok, ezért a matematikai megjelenítés sem lesz egyforma. 


e Még ha a megjelenítés és a funkcionalitás ugyanaz is, a matematikai elemek dinamikus 
viselkedése, együttműködése különbözik — például a metszéspontok megjelenítése más. 


2. A GeoGebra JavaScriptre való átírása (portolása). Mivel adottak a lehetőségek (HTML5 tech- 
nológiák), mi jut eszébe egy ízig-vérig programozónak: oké, nézzük, mi a funkcionalitás, eset- 
leg kukkantsunk a kódba, és írjuk meg JavaScriptben. Ez vonzó is, hisz így tényleg úgy optima- 
lizáljuk, ahogy akarjuk, és imádunk JavaScriptben kódolni! Ám pillantsunk csak a terminálba 
picit: 


apalapa:~/M/workspaces/GeoGebra$ find -name х.јауа | wc -l1 

3710 

apalapa:~/M/workspaces/GeoGebra$ find -name х.јауа | xargs cat | wc -1 
921524 


Mint látjuk, 3710 java fájlról és összesen 921 524 sornyi kódról van szó. Ahogy említettem, 
ez egy több mint tíz éve fejlődő alkalmazás. Kézzel átírni bizony nem lenne egyszerű feladat. 
Marad hát a portolás! Ezt választottunk végül is. 





Shttp://jsxgraph.uni-bayreuth.de/wp/ 
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2.2. GWT- Javából JavaScriptet 


Szerencsére léteznek megoldások Javából JavaScriptre való portolásra, fordításra. A leghasználha- 
tóbbnak а GWTf-t találtuk. Több szempontból is megnyerő: Eclipse-ben történik a fejlesztés, а 
GWT plugin telepítésével. A Java JRE-nek elég nagy része támogatott, és mivel felhasználóbázisa 
hatalmas, rengeteg .jar könyvtár készül hozzá. Folyamatos fejlesztés alatt van, havonta jönnek ki 
frissítések (HTML5 támogatottság, touch események, a JRE kompatibilitás bővítése, böngészőop- 
timalizálás, hogy csak párat említsek). A fejlesztő által készített Java kódot több JavaScript fájlra 
(permutációra) fordítja le , melynek betöltése egy szelektor script segítségével történik, aszinkron 
módon. Így a különféle böngészők különféle .js fájlokat kapnak az optimális működés elérésének 
érdekében. Mivel a .js fájlok nem kerülnek „emberi fogyasztásra” — csak a böngészőnek kell értel- 
meznie őket - , teljes mértékben lecsupaszított, minimalizált, szinte gépi JavaScript kódot kapunk. 
Lássunk egy képet az eredményről (csak erős idegzetűeknek). 
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А GWT plugin azon túl, hogy а fordítást megteszi, tökéletes debug környezetet is biztosít szá- 
munka, azaz úgy debugolhatjuk kódunkat, mintha normál Java alkalmazást debugolnánk. A kód a 
böngészőben fut, és a GWT plugin részeként kapott webszerver létesít kapcsolatot aböngészőnkben 
futó GWT plugin, valamint az Ecipse-ben futó kódunk között. Töréspontokat rakhatunk, objektumo- 
kat vizsgálhatunk, minden teljesen elérhető, és működik. Bár nagy rajongója vagyok a Firebugnak, 
JavaScriptben ilyen szintű debug tulajdonságokkal még nem találkoztam. Mindezen rendszer mö- 
gött a Google neve van, mely talán valamekkora biztosíték hosszú távra. Ezért döntöttünk hát a 
GWT mellett. 

Persze nem minden fenékig tejfel. Bár a JRE nagy része támogatott, és ez a támogatás folya- 
matosan növekszik", egy natív Java alkalmazás ennél sokkal többet használ. Ha olyan kódrészlettel 
találkozunk, mely nem támogatott, a lehetőségeink a következőek: 


e , Google a barátunk". Rákeresünk, hátha valaki már megírta, és átrakta GWT-re. 





$http://code.google.com/int1l/hu-HU/webtoolkit/ 
Thttp://code.google.com/intl/hu-HU/webtoolkit/ doc/latest/RefJreEmulation.html 
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e Google még mindig a barátunk. Ha nincs GWT-ben, megnézzük, van-e Javában, és átalakítjuk 
a kódot, hogy kompatibilis legyen GWT-ben is. (Itt olyan fellelhető, szabad Java kódimple- 
mentációkra gondolok, mint például az OpenJDK). 


Megírjuk mi magunk Javában. 


Megírjuk JavaScriptben. Ezt a JSNI (JavaScript Native Interface) GWT funkcionalitás bizto- 
sítja, ám nem hiába hagytam ezt utoljára: a tiszta JavaScript kód nem lesz optimalizálva, és 
nem tudjuk debugolni Eclipse-ben. Mindettől függetlenül sokat használtam én is olyan esetek- 
ben, ahol implementálatlan HTML5 funkciókat kellett belefejleszteni a projektbe (<canvas> 
tag, drag and drop, touch events, külső JavaScript könyvtár— pl. MathJax használata – , stb.). 
Érdemes mindig figyelni az új frissítéseket, mert a funkcionalitás folyamatosan bővül, így 
most már mind a <canvas> tag, mind a touch events natívan implementálva van a GWT-ben, 
és ilyenkor érdemes létező JavaScript kódunkat átrakni (mint ahogy ez meg is történt). 


Az, hogy hogyan történjen a portolás, szintén érdekes kérdés. Választhatunk, hogy kódot porto- 
lunk vagy funkcionalitást. Ha kódot portolunk, akkor talán érdemes függőségi vizsgálatot csinálni 
a Java kódban, és azokkal az osztályokkal kezdeni, melyek a legkevésbé dependensek, így nem 
veszünk el a hibajelzések között (annyira). Ha funkcionalitást portolunk, mint ahogy én is tettem 
ennél a projektnél (először csak egy egyenest szerettem volna rajzolni két pontra), akkor elkezdhet- 
jük a funkcionalitáshoz szükséges kódok portolását, így előrehaladni. Készüljünk fel, hogy nem fog 
gyorsan menni nagy projekteknél: nálam az Eclipse 6000 hibajelzést dobott fel, mikor az első Java 
package-eket átmásoltam az új GeogebraMobile GWT projektbe. 

Fontos, hogy a GWT ízig-vérig Web projekt. Teljes mértékben úgy használhatjuk, mint szeretett 
függvénykönyvtárunkat (pl. jQuery), megírhatjuk a HTML-t, stílust CSS-sel, és csak a JavaScriptet 
írjuk – Javában. Tehát nem Java projektet írunk, hanem Web projektet. 

A GeoGebra egy MVC rendszer. A modell a kernel package, mely tartalmazza a GeoElemek 
(pontoktól az alakzatokig, függvények, szöveg, képek, csúszka stb.) osztályait és algoritmusait. Az 
EuclidianControler. java a kontroller, mely összeköti a kernelt az EuclidianView.java-val (ez a view), 
mely gyakorlatilag egy Jpanel. A konkrét rajzolás a java.awt.Graphics2d osztállyal történik. 

Igazából magam is meglepődtem, mennyi hasonlóság van a Java kód működése és a GWT-s lehe- 
tőségek között. Mindkettő eseményvezérelt kód, és a Graphics2d csomag metódusai szinte 100%-ig 
megegyeztek а GWT <canvas> tag implementációjával. Így, bár voltak nehézségek, a portolás tech- 
nikailag lehetséges volt, és szépen haladt. Legfontosabb trükkök: НТМІ5 File АРІ és Drag&Drop 
használata a .ggb fájlok megjelenítéséhez (csak behúzzuk az oldalba, teljesen kliens oldali unzip — 
a JSXGraph JavaScriptben megírt kitömörítő kódjával), MathJax használata a LaTeX egyenletek 
megjelenítéséhez. 

Több hónap telt el, megjelentek az első iPadek. Markus izgatottan írt egy konferenciáról, ahol 
csak úgy mellékesen bemutatta a GeoGebraMobile-t: , Gabor, your work is very important. Everyone 
is speaking about iPad and Android here”. Ekkor még két kollégám szállt be a fejlesztésbe, így már 
hárman vittük tovább a projektet. 

Azonban mindez mégsem tökéletes. Mivel gyakorlatilag másoljuk az eredeti kódot, ezért így 
mindig két kódbázis létezett: a GeoGebra, és emögött elmaradva a GeoGebraMobile. Egyre több- 
ször és többször kaptunk megjegyzéseket, hogy , hú, ez nagyon tuti, de jó lenne, ha támogatná ezt a 
funkciót is, mint az eredeti. . . ". Itt most csak a kernel funkcionalitásról beszélek, tehát egyes Geo- 
Elemek vagy kapcsolataik nem megfelelően vagy még egyáltalán nem működtek a mobil verzióban. 
Ahogy közeledett a 4.0-s GeoGebra verzió, a fejlesztők egyre többet commitoltak, mi pedig egyre 
jobban elmaradtunk. Nyáron a GSoC (Google Summer of Code) is támogatta a fejlesztést, így egy 
negyedik fejlesztő GUI kódot is rakott a GeoGebraMobile-ba (amely addig csak megjelenítésre volt 
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képes, lásd fent a képet), melynek eredményeképp 3 különböző kódbázis lett. Ekkor már láttuk, hogy 
ez így nem lesz jó. 

Mindenesetre eljutottunk odáig, hogy ha a GeoGebraTube" oldalt mobile böngészőben nyitjuk 
meg, a GeoGebraMobile JavaScript kód által feldolgozott szerkesztést kapjuk. Persze, mint írtam, 
vannak szerkesztések, melyek nem működnek, vagy csak részben, de 70%-os sikerrel járunk, és 
kipróbálhatjuk Android vagy iPad — iPhone — iPod Touch eszközeinken а szerkesztéseket. Ha nagyon 
akarjuk, még Kindle e-book olvasón is megnézhetjük. 


3.  GeogebraWeb 


Augusztus végén, a nemzetközi GeoGebra konferencián összeültünk mi fejlesztők, és egyéb work- 
shopok mellett azt is megvitattuk, mi lenne a legjobb. Arra jutottunk, hogy nem választhatjuk szét 
a két projektet, mivel most már láttuk, mekkora teret nyert а HTML5, a mobile eszközök, és nem 
mellékesen (sajnos) mennyire bukik a Java. A végeredmény-tervezet így szólt: három projektet kell 
vinnünk tovább. Azt a részt, mely nem kompatibilis a GWT-vel (GUI, Swing stb.), a desktop verzi- 
óba tesszük. A Desktop projekt függeni fog egy másik projekttől, mely a Common nevet kapja, és 
már GWT kompatibilis kódot tartalmaz. Aki csak az eredeti GeoGebra fejlesztését viszi, a további- 
akban ezen két projekttel kell csak foglalkozzon: a kódjának azt a részét, amely nem kompatibilis 
a GWT-vel, a Desktopba rakja, amelyik pedig az (ez nagyrészt a logikai rész, valamint az algorit- 
musok csoportja), megy a Commonba. A Commont néha leellenőrzi a GWT fordítóval, hogy nem 
került-e bele véletlenül inkompatibilis kód. 

A Commontól függ a harmadik projekt is: a Web. Ez a régi GeoGebraMobile, ami a logikát 
(modellt) a Commonból veszi, a megjelenítést és egyéb webspecifikus dolgokat pedig önmaga imp- 
lementálja. Az elmélet tehát megszületett, a kivitelezés folyamatban van. 


3.1. Git vagy Svn 


Tervezés közben többször felmerült a Git?. Mivel a GeoGebra open source projekt, a GitHub megle- 
hetősen elterjedt, és maga a Git igen csábító funkcionalitással rendelkezik, úgy döntöttünk, teszteljük 
egy picit: Kovács Zoltán kollégámmal ráálltunk. Zoli munkájának eredménye egy folyamatosan Svn- 
ből frissülő геро lett a GitHubon!?, én pedig beleszerettem a lehetőségekbe, melyeket a portolásnál 
nyújt: a kézreálló branching-merging funkciókba, illetve abba, mennyire jó a kód és fájlkövetés, hogy 
a két legfontosabbat említsem. Hozzáteszem, mindketten parancssor-mániások vagyunk, így hát itt 
az Eclipse-t tényleg , csak mint szerkesztőt" használtam, és a Gittel a parancssorból játszottam. 
Szóval mi beleszerettünk, de csak ketten vagyunk a mintegy 30 fejlesztőből,a többiek már meg- 
szokták és megszerették az Svn- Trac párosítást. Ahogy utánanéztünk, rájöttünk, hogy a Trac пет 
igazán implementált még Gittel (nyilván nincs is szükség rá, hisz a history a gépünkön van), és 
nem valószínű, hogy el tudjuk érni azt a funkcionalitást, amelyet már a begyakorolt Ѕуп – Trac páros 
nyújt. Kiemelném, hogy ez nem a Git hibája, egyszerűen az a koncepcióváltás, hogy a webes felü- 
letről áttérjünk egy offline felületre, valószínűleg megölné a projektet (csak mi ketten dolgoznánk 
tovább :-)). Fokozza még a problémát az Eclipse EGit pluginja, mely , csak" annyira bugos néha, 
mint a Subversive Svn plugin. Mivel azt már megszokták, és senki nem akar parancssorból dolgozni, 
itt 18 alulmaradunk. Ráadásul azoknak, akik portolni akarnak a history követése érdekében (tehát 
mikor átrakunk egy fájlt a Desktopból a Commonba), a Subversive sem jó, mert nem Svn move-ot 
használ, hanem egyszerűen törli, majd újra létrehozza a fájlt, így eltűnik a history. A portoláshoz a 





S$hnttp://www.geogebratube. org/ 
Jhttp://git-sem. com/ 
Whttps://github. com/geogebra 
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Subclipse plugint kell használnunk, ami már megfelelően megteszi a bejegyzést a historyba, és így 
visszakövethető a portolt fájl is. 

Egyelőre tehát dobtuk a Gitre való átállást, és csak a fanatikusok fognak vele dolgozni, lásd 
alább. 


3.2. Fejlesztés menete – meglett végül is 


Így hát maradtunk az Svn-nél, egyelőre. Ha idáig eljutottál, kedves olvasó, és felmerül benned, hogy 
fejlesztenél (annak nagyon örülnénk ám! :-)), az alábbi módokon teheted meg: 


1. Svn jó nekem: Amennyiben ebbe a csoportba tartozol, csak el kell olvasnod a 
http: //www.geogebra.org/trac/wiki/SetUp oldalt, és már mehet is! 


2. Svn jó nekem, és a GeoGebraWeb is érdekel: A fenti wiki oldal elolvasása után a Common 
projekt mellett a Webet is le kell szedned. Erről még készül a wiki. Mindemellett a Subversive 
plugin helyett a Subclipse-t kell használnod, hogy a portolt fájl historyja megmaradjon. 


3. Git fanatikus vagyok: Igazi álmom lenne, hogy a Git repo és az Svn repo két irányú szinkron- 
ban működne, tehát egy automatizmus időnként szinkronizálná a két repót, így bármelyikben 
történik fejlesztés, az látszana a másikban is. Ez valószínűleg tényleg álom. Ám ami biztos 
működik, az a git-svn. Az Svn repositoryt a git-svn paranccsal leszedjük, majd mehet a fej- 
lesztés. Célszerű minél lineárisabb historyt fenntartani, hisz az Svn úgysem fog tudni másfélét 
kezelni. Ez azt jelenti, hogy a branchokban végzett munkák után rebase-t kell használni, va- 
lamint emészthető committá sguasholni a commitokat (jó-jó, de ez egy szakmai cikk, nem? 
:-)), hogy az Svn-nek fogyasztásra alkalmas legyen. A következő feladat ezek Ezután a git 
svn rebase futtatása, majd git svn dcommit-tal felküldeni a változtatásainkat. A munka többi 
része persze mehet Eclipse-ben, de ezt parancssorból vagyunk kénytelenek megcsinálni, ami 
egy Git usernek úgyis elengedhetetlen. 


4. Konklúzió 


Ilyen megoldott és még megoldandó problémák vannak most a GeoGebra életében. Mivel ez az 
írás áttekintő jellegű volt, egyrészt a helyszűke, másrészt , ha az egyik momentumot kifejtem, mi- 
ért pont azt fejtsem ki" hezitálásom miatt, bármi szakmai – nem szakmai kérdésed, kérlek, küldd a 
gabor@geogebra.org-ra. Örömmel fogok válaszolni, ha tudok; ha nem tudok, keresek olyat, aki tud. 

Általános következtetésként pedig egy mondat: az bebizonyosodott, hogy Java projektek webre 
való portolása lehetséges, és megéri nekikezdeni. 
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Napjaink informatikai rendszerein több tucat alkalmazás ömleszti magából az események napóit, 
ráadásul sok esetben teljesen más formátumban, operációs rendszeren és protokollon keresztül. 
A hatékony loggyűjtes alapvető feltétele annak, hogy ezek az események később kereshetőek, 
elemezhetőek és értékelhetőek legyenek. 

Az nxlog egy olyan naplózó eszköz, amely segítségével több platformon tudunk logot gyűj- 
teni, továbbítani és tárolni. Az apache stílusú konfigurációs formátumával és egyszerűen használ- 
ható saját nyelvével egy olyan nyílt forráskódú eszközt kapunk, amely megpróbálja megteremteni 
az átjárhatóságot a különféle formátumok és protokollok között. 
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3 A FELADAT 





1. Miért naplózzunk? 


Napjaink informatikai rendszerein több tucat alkalmazás ömleszti magából az események naplóit, 
ráadásul sok esetben teljesen más formátumban, operációs rendszeren és protokollon keresztül. A 
hatékony loggyűjtes alapvető feltétele annak, hogy ezek az események később kereshetőek, elemez- 
hetőek és értékelhetőek legyenek. Ez a probléma mára már kulcsfontosságúvá vált, ezért a kérdés 
nem is arról szól, hogy kell-e naplózni, hanem hogy mivel és hogyan. 


2. Az nxlog története 


A cél egy multiplatformos napló gyűjtő és menedzsment eszköz létrehozása volt, amely minimális 
erőforrásigény mellett nagy teljesítményre képes és a syslog protokollon túl több naplóformátumot 
és forrást is képes kezelni. Ennek megvalósítására több lehetőség is kínálkozott, többek között az 
rsyslog, a syslog-ng és az msyslog továbbfejlesztése. A legnagyobb problémát ezeknek a Windows 
operációs rendszerre portolása, illetve az erős syslog protokollhoz való kötöttségük jelentette. A hely- 
zet azóta némileg változott, de abban az időben architekturálisan sem volt kielégítő ezek egyike sem. 
Nem voltak képesek többszálú feldolgozásra, a modularitás is csak az msyslog esetében volt adott. 
Az utóbbival tettünk is egy kísérletet néhány kifejlesztett modul formájában, azonban hamar be kel- 
lett látni, hogy a jelen kor követelményeit csak egy új szoftver segítségével fogjuk tudni kielégíteni. 
Így született meg az nxlog. Azóta több sikeres bevezetésen vagyunk túl ahol heterogén környezetben 
különféle Windows és Linux rendszerek naplóit gyűjti központosítottan, napi több millió esemény 
feldolgozása mellett. 

Később úgy döntöttünk, hogy ezt elérhetővé tesszük az open-source közösség számára is, így 
a forráskódja – mely jelenleg körülbelül 90 000 sor C kód— 2011. október 14-én került publikálásra. 
Ez elérhető a SourceForge-on keresztül GPL/LGPL licenc alatt! . Itt a forráskódon kívül bináris 
csomagokat is közzétettünk Debian, Ubuntu, Red Hat és Windows operációs rendszerekhez. 


3. А feladat 


На szétnézünk а naplózás tengerén, akkor elképesztően változatos módszerekkel, formátumokkal, 
protokollokkal találjuk szembe magunkat. Először kukkantsunk be a kedvenc Linux rendszerünk 
/var/log könyvtárába. Ez az a hely ahova a rendszernaplók kerülnek. Itt a következőkkel találkoz- 
hatunk: 


/var/log/messages 


Oct 27 23:09:01 mephisto CRON[31358]: pam unix(cron:session): session closed 


for user root 


Ezt a fájlt a syslog daemon írja, azonban a formátuma mégsem azonos a syslog protokolléval, 
mert a sorok elejéről hiányzik a priority érték amely a súlyosságot és a facility-t tartalmazza. 
A standard installációkon a syslog daemon úgy van konfigurálva, hogy ezek alapján szétvá- 
logatja különböző fájlokba a logokat. Húsz éve ez valószínűleg elegendő volt így, mára már 
véleményem szerint ez sok esetben csak hátrány. 


/var/log/dmesg 


[ 0.072001] Booting processor 1 APIC 0x1 ip 0x6000 





!http://nxlog.org/ 
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А formátuma ennek sem hasonlít a syslog daemon által írt állományokéra, de legalább nem 
bináris. 
/var/log/dpkg.log 
2011-10-12 19:22:50 startup archives install 


Ez sem syslog. . . 


/var/log/wtmp 


Bináris formátum, ne is próbáljuk szöveges fájlként nézegetni. 


/var/log/apache2/access.log, /var/log/apache2/error.log 


Habár ezeket az Apache írja, a formátumuk még véletlenül sem azonos, de még csak az eddi- 
giekre sem hasonlítanak. 


Még oldalakon keresztül sorolhatnám ezeket a példákat amelyek csak a /var/log alatt találunk. 
Szinte minden naplófájl más, még az idő, és dátum formátumok sem azonosak egyikben sem. Ter- 
mészetesen ez halandó ember számára ez nem okoz különösebb problémát, hogy értelmezze a tar- 
talmukat, de ha valamilyen elemzőbe be szeretnénk tölteni ezeket, akkor már nem olyan egyszerű a 
felolvastatásuk. 

A fájlokból megszerezhető naplókon kívül még létezik számos más forrás, például különféle 
hálózati protokollokon keresztül is lehetőségünk van naplókat fogadni és küldeni. Ezen kívül létezik 
sok olyan alkalmazás, amely adatbázisba naplóz. 

Ha a GNU/Linuxtól kicsit eltávolodunk és más elterjedt operációs rendszereken nézünk szét, ak- 
kor azt látjuk, hogy nem csak a szabad szoftveres közösség megy a saját feje után, hanem például 
a Microsoft Windows rendszerek alatt is számtalan különféle naplófájlformátummal találkozhatunk. 
Ezen kívül ott van még a sortörésre használt karakter, a különféle karakterkódolások, a többsoros ese- 
ménynaplókat tartalmazó állományok problémája. A Windows EventLog rendszernaplókat ráadásul 
nem is lehet közvetlenül olvasni, mivel ez egy bináris formátumú cirkuláris logfájl. Itt az operációs 
rendszer kínál egy API-t a naplóesemények lekérdezésére. Ennek legalább annyi előnye van, hogy 
nem a naplógyűjtőnek kell felolvasni az eseménynaplót, hanem ez már strukturált formában elér- 
hető. Mindezeket még sorolhatnám, de valószínűleg sokunknak volt már dolga a változatosabbnál 
változatosabb naplókkal. 

Természetesen ha csak egy fajta forrásból érkező eseményekre vagyunk kíváncsiak, akkor relatív 
egyszerű dolgunk van az adott formátum beolvasásával. Azonban ha az eseményeket centralizáltan 
összegyűjtve szeretnénk vizsgálni— amely ahhoz szükséges, hogy átfogó képet tudjon nyújtani az 
infrastruktúra működésének egészéről is — akkor sajnos ezzel a sokszínűséggel mindenképp kényte- 
lenek leszünk megbirkózni ahhoz, hogy minden esemény naplóját el tudjuk hozni, majd tárolni. 

Egyelőre vegyük a két leggyakoribb és legelterjedtebb naplózási módszert, a UNIX-os syslog-ot 
illetve a Windows EventLog-ot. Ha ezeket gyűjteni tudjuk, akkor az operációs rendszer esemény- 
naplóinak a jelentős részét le tudjuk fedni. A syslog esetében minden naplóüzenet tartalmazza az 
esemény idejét, a gép nevét, a súlyosságot, az alrendszert, az alkalmazás vagy folyamat nevét és az 
általa naplózott üzenetet. Az EventLog esetében ennél kicsit jobb a helyzet, mert itt néhány mező- 
vel többet ad át nekünk az API, például a felhasználó nevét és a domain-t is. Azonban sok esetben 
ennél még több információra van szükségünk amikor bizonyos szempontok alapján megpróbálunk 
eseményeket keresni vagy kimutatásokat és elemzéseket futtatni. Például a hálózati kapcsolatok nap- 
lózásakor az üzenetben általában eltárolódik a forrás és a cél IP címe. Ha egy olyan kimutatásra 
lenne szükségünk amely összegzi, hogy mely szervereinkre milyen címekről érkeztek kapcsolatok, 
akkor ehhez az eseménynapló üzenet részéből kell előbányászni a szükséges adatot, mégpedig az IP 
címeket. Úgy gondolom ebből a példából is jól látszik, hogy nem elég a naplókat egyszerűen csak 
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eltárolni, hanem a legtöbb esetben bizonyos feldolgozásra is szükség van ahhoz, hogy hatékonyan 
tudjunk keresni, szűrni, riportokat készíteni és elemzéseket végezni. Ha csak natúr belehányjuk va- 
lamilyen konténerbe (adatbázisba vagy fájlokba), attól ez még nem garantálja, hogy a későbbiekben 
ez így ebben nyers formában elegendő lesz. Hurrá, hogy le van időpecsételve, tömörítve és még 
titkosítva is. 


4. Аз nxlog képességeiről 


A fentiekből jól látszik, hogy komoly fába vágja a fejszéjét aki egy általános célú naplózó fejleszté- 
sébe kezd. Az nxlog formájában igyekeztünk egy olyan eszközt megalkotni, amely hatékonyan képes 
kielégíteni ezeket az elvárásokat. A különféle formátumok és források támogatásán kívül essen még 
szó, hogy milyen képességeket láttunk fontosnak implementálni. 


4.1. Multi-platform 


Ahhoz, hogy egy heterogén környezetben különféle operációs rendszerektől beérkező naplókat gyűj- 
teni lehessen, elengedhetetlen, hogy ezeken a rendszereken képes legyen futni és ne csak távolról 
tudjon logokat fogadni valamilyen hálózati protokollon keresztül. Ezáltal nem kell többféle naplózó 
szoftverrel küzdenünk. Az nxlog jelenleg a GNU/Linux, Microsoft Windows és HP- UX operációs 
rendszereket támogatja. Tervbe van véve más operációs rendszerekre portolása is és ez a tapasztala- 
tok alapján várhatóan nem fog megoldhatatlan akadályokba ütközni. 


4.2. Erősen moduláris 


A körülményektől függően a legtöbb esetben nincs minden funkcióra szükség, így az nxlog csak azo- 
kat a modulokat tölti be, amelyre a konfigurációs állománya hivatkozik. Ezáltal az erőforrásigénye is 
jelentősen csökken. A modularitásnak és a C nyelvű implementációnak köszönhetően a memóriaigé- 
nye igen kevés. Hamarosan bővebben is lesz szó a jelenleg elérhető nxlog modulokról és az ezeket 
alkalmazó architektúrájáról. 


4.3. Biztonságos működés 


A naplózáshoz nincs feltétlenül szükség arra, hogy root jogosultságokkal fusson a program amely 
így komoly veszélyeket rejthet magában. Az nxlog képes arra, hogy a root jogoktól megszabadulva 
egy adott felhasználó jogaival fusson és így korlátozható a működése. GNU/Linux alatt szükség 
esetén képes capability-ket használni, ha bizonyos funkciók ezt megkövetelik. 


4.4. Többszálú párhuzamos feldolgozás 


Ma már a mobiltelefonokban is többmagos processzorok dolgoznak. Az nxlog képes egyszerre több 
processzort illetve processzormagot használni azáltal, hogy több szálon dolgozza fel a logokat. Ezen 
párhuzamosított működés nélkül előfordulhatna, hogy a kimeneti oldali leterhelés miatt nem lenne 
képes a bemeneten az UDP csomagokat kellő gyorsan fogadni, ez pedig csomagvesztéssel járna. 
Az пх1ор jól skálázódik a hálózati kapcsolatok számának növekedésével, egyszerre képes akár több 
ezer kapcsolatot kezelni. A többszálú működésnek köszönhetően kiemelkedő teljesítményre képes, 
másodpercenként százezres nagyságrendben tud eseménynaplókat feldolgozni. 
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4.5. Egyszerű konfigurációs szintaxis és nyelv 


Az nxlog Apache-stílusú konfigurációs fájlokat használ, mint ezt hamarosan látni fogjuk néhány pél- 
dán keresztül. Ez a formátum igen elterjedt a nyílt forráskódú szoftverek körében ezért várhatóan 
nem fog akadályokba ütközni a megértése. Ezen kívül saját nyelve van amellyel nagyon rugalmasan 
testre szabható a kívánt naplófeldolgozás. Ez egy egyszerű programnyelv amely leginkább a Perlhez 
hasonlít. Akinek volt már dolga naplófeldolgozással az jó eséllyel ismeri a Perlt is, ezért tartottuk jó- 
nak bevezetni ezt a szintaxist valamilyen nehezen érthető makró-nyelv vagy sablon rendszer helyett. 


5. Modulok 


Az nxlog négy fajta modult képes használni: input, processor, output, extension. Az első három 
közvetlenül érintkezik a naplóüzenetekkel és ezeket össze kell láncolni egy útvonalba annak érdeké- 
ben, hogy bármiféle naplófeldolgozás történhessen. Szemléletesen a láncolás a következőként néz 
ki: input — [processor —] output. 

Az extension modulok nem részei egyik feldolgozó láncnak sem, ezekkel az nxlog funkcionalitá- 
sát lehet kibővíteni. Elsősorban az nxlog nyelvből meghívható speciális függvényekkel és eljárások- 
kal lehet kiterjeszteni a képességeit. Ilyenek lehetnek a parser-ek, konverziót megvalósító műveletek. 
Ennek további előnye az, hogy az [/O-t az input és output modulok transzparens módon képesek 
végezni, így például egy protokoll feldolgozáshoz nem szükséges megírni a hálózati kapcsolatok 
kezeléséért felelős kódot. 

Az extension modulok az xm_, az input modulok az im , a feldolgozó (processor) modulok a 
pm , az output modulok pedig az om prefixszel vannak ellátva. 


Jelenleg a következő nxlog modulok léteznek: 


im арі A libdbi adatbázis absztrakciós rutinkönyvtár segítségével ezzel а modullal adatbázisból 
tudunk naplót elhozni. A támogatott adatbázisok: MySQL, PostgreSQL, MSSQL, Sybase, 
Oracle, SOLite, Firebird. 


im exec Az im exec modul a konfigurációs állományban megadott parancsot indítja el és ennek 
a kimenetét olvassa. 


im file Ezzel a modullal fájlból van lehetőségünk logot elhozni. 
im internal Az nxlog saját üzeneteit ezzel a modullal tudjuk az útvonalakba beküldeni. 


im kernel Ez a modul a Linux kernel üzeneteket olvassa. 


H- 


m_mark A megadott időközönként periodikusan generál egy üzenetet ahogy ezt sokan megszok- 
hatták syslogd esetében. 


im mseventlog A Microsoft Windows operációs rendszereken az EventLog rendszernaplót ol- 
vassa ez a modul. 


im null Ez a modul nem generál semmilyen logot, elsősorban tesztelési célra készült. 


im ss1 TLS/SSL kapcsolatokat fogadva lehetőségünk van titkosított csatornán keresztül napló- 
üzeneteket fogadni. 





H- 


m_tcp Titkosítatlan TCP kapcsolaton fogad naplóüzeneteket. 
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. udp UDP protokollon keresztül képes naplóüzeneteket fogadni, mint például az RFC 3164-ben 
definiált syslog üzeneteket. 


. uds Unix Domain Socket-ről képes naplóüzeneteket olvasni, mint amilyen tipikusan a /аеу/1од. 


. blocker A láncban előtte álló modult blokkolja. Elsősorban tesztelési célokra készült. 


. buffer Memóriába illetve diszkre puffereli a naplóüzeneteket abban az esetben, ha a kimeneti 
oldal nem tudja elég gyorsan (vagy egyáltalán) küldeni vagy írni ezeket. 


. filter Reguláris kifejezés segítségével tudunk naplóüzeneteket szűrni oly módon, hogy csak 
azokat engedi tovább, amelyekre illeszkedik a mintánk. 


. norepeat Az egymás után ismétlődő azonos naplóüzeneteket összevonja egy "last message 
repeated x times" üzenetbe, így valamilyen szándékolt vagy hibás működés által előidézett 
DOS lehetősége csökkenthető. 


pm null Önmagában nem végez semmilyen feldolgozást, ám az nxlog nyelv segítségével végre- 


hajtható különféle feldolgozás a rajta áthaladó üzeneteken, ezért nem teljesen haszontalan. 


pm pattern Egy XML alapú szabálybázist használ amelyben a mintaillesztési szabályokat defini- 








álhatjuk. Mintacsoportok segítségével illetve adaptív működési algoritmusával jóval optimáli- 
sabb működésre képes, mintha ezt felsorolásszerű reguláris mintákkal próbálnánk megoldani. 


. transformer Segítségével az nxlog nyelv használata nélkül tudunk CSV és syslog kimene- 
tet olvasni, illetve a kimenetet ezekre a formátumokra alakítani. 


. blocker A segítségével beragadást tudunk szimulálni a kimeneti oldalon. 


. dbi A libdbi adatbázis absztrakciós rutinkönyvtár segítségével ezzel a modullal adatbázisba 
tudunk logolni. 


. exec A konfigurációs állományban megadott parancsot indítja el és ennek a bemenetére írja 


az üzeneteket. 
file Segítségével fájlba lehet a naplóüzeneteket irányítani. 


. nul1 A fogadott üzeneteket eldobja, mintha a /dev/nul1-ba írnánk. 





_551 TLS/SSL kapcsolatot kezdeményezve lehetőségünk van titkosítva továbbítani а naplóüze- 
neteket. 


. tep TCP kapcsolatot kezdeményezve továbbít naplóüzeneteket. 
. udo A BSD Syslog szabvány által is használt UDP protokollon tud naplóüzeneteket küldeni. 
. uds Segítségével Unix domain socket-re tudunk naplózni. 


. csv Az nxlog nyelvből meghívható parse csv() illetve to csv() eljárásokat exportál. А 
CSV formátumát a modul paraméterezésével tudjuk megadni. 


. charconv Kódkészlet konverzió végrehajtására alkalmas függvényt exportál és automatikus 
kódkészlet felismerésére is képes. 


. syslog А BSD syslog protokollban használt sor-orientált üzenetek felolvasására és formázá- 
sára alkalmas eljárásokat kínál. 


. exec Két eljárást exportál, amelyekkel aszinkron és szinkron módon külső program végrehaj- 
tására van lehetőségünk. 


28 





6. Gyűjtsünk logot végre 


Lássunk egy konkrét példát végre, hogy miként is tudunk centralizáltan naplót gyűjteni az nxlog 
segítségével. Tegyük fel, hogy a hálózatunkban van egy Windows-t futtató gép illetve egy Linux 
szerver amelyen a naplókat szeretnénk tárolni. 

A Windows-os gép konfigurációs állománya a következőképpen néz ki: 


define ROOT C:\Program Files (x86)\nxlog 
define CERTDIR %ROOT%\cert 
define CONFDIR %ROOT%\conf 
define LOGDIR %ROOT%\data 








Moduledir %ROOT%\modules 
CacheDir %ROOT%\data 

Pidfile %ROOT%\data\nxlog.pid 
SpoolDir %ROOT%\data 





<Input in> 
Module im_mseventlog 
</Input> 


<Output out> 








Module om ssl 
Host 192.168..1..1 
CertFile %CERTDIR%/client-cert.pem 
CertKeyFile %CERTDIR%/client-key.pem 
CAFile %CERTDIR%/ca.pem 
Pört 1514 
</Output> 
<Route 1> 
Path in => out 


</Route> 


Ez egy viszonylag egyszerű konfiguráció, az nxlog az EventLog rendszernaplót olvassa és titko- 
sított SSL csatornán továbbítja a linuxos gép felé. Az om_ss1 modul működéséhez PEM formátumú 
tanúsítványokra van szükségünk. Ezek generálására itt nem térünk ki. Az openssl segítségével pa- 
rancssorból is tudunk ilyeneket generálni, illetve több nyílt-forráskódú grafikus alkalmazás is létezik 
erre a célra, mint például a gnomint. 

A Linux szerverünk beállítása pedig az alábbi: 


define CERTDIR /var/lib/nxlog/cert 





<Input sslin> 





Module im_ssl 
CertFile %CERTDIR%/server-cert.pem 
CertKeyFile %CERTDIR%/server-key.pem 
CAFile %CERTDIR%/ca.pem 
Host 0.0.0.0 
Рогі 1514 

</Input> 


<Input udpin> 
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Module im udp 
Port 514 
</Input> 


<Output winlog> 

Module om file 

File "/var/log/win.1log?" 
</Output> 


<Output syslogfile> 

Module om file 

File "/var/log/syslog.log" 
</Output> 


<Route sslwin> 
Path sslin => winlog 
</Route> 


<Route syslog> 
Path чар1п => syslogfile 
</Route> 


A Windows felől SSL-en érkező naplóüzeneteket az im ss1 modul sslin példánya fogadja és 
ezeket a win. log állományba írja. Ezen kívül a szerver az 514-es UDP porton is fogad üzenete- 
ket és ezeket közvetlenül a syslog .log fájlba írja. Mivel itt nem történik syslog protokoll szerinti 
értelmezés, ezért a kimeneti állományba is az eredeti üzenetek kerülnek, tehát syslogd által írt fáj- 
loktól eltérő módon a sorok elején a teljes syslog fejléc is látható. Természetesen ha szükséges, a 
pm transformer modul segítségével a formátum a syslogd-nél megszokott formára hozható. 


7. Mezők 


Sok esetben szükség van arra, hogy a naplókat más formára hozzuk, rendszerezzük, szűrjük stb. Ez 
általában csak úgy oldható meg, ha az üzenet tartalmát vizsgáljuk. Ha az eredeti üzenet strukturált 
formában érkezik, mint pl. a Windows EventLog esetében, akkor már eleve több mező is tartozik az 
üzenethez. Ezt lehetőségünk van még tovább bontani vagy más mezőket hozzáadni az nxlog nyelv- 
ből illetve további modulok segítségével. A modulok dokumentációjában megtalálható, hogy melyik 
milyen mezőket tölt. A mezőkre bontást az alábbi példával szemléltetjük amelyben egy syslog for- 
mátumú naplóüzenet látható. 
<30>Nov 21 11:40:27 log4ensics sshd[26459]: Accepted publickey for john from 
192.168.1.1 port 41193 ssh2 
Eztaparse syslog bsd() eljárás vagy а рт transformer modul segítségével felolvastat- 
juk, majd további mintaillesztéssel még néhány fontos mezőt kivágva a következő eredményt kapjuk: 


AuthMethod publickey 
SourcelPAddress T92 LES Da 
AccountName john 

SyslogFacility DAEMON 
SyslogSeverity INFO 

Severity INFO 

EventTime 2009-11-21 11:40:27.0 
Hostname log4ensics 

ProcessID 26459 

SourceName sshd 
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Message Accepted publickey for john from 192.168.1.1 port 41193 ssh2 


Ezek után lehetőségünk van rá, hogy a mezők alapján egyszerűen tudjunk szűrni vagy más logfel- 
dolgozási döntést hozni. A mezők tipizáltak, a következő típusokat kezeli az nxlog: string, datetime, 
boolean, integer, ipv4address, ipv6address. Létezik egy speciális mező, a Sraw event. Ez a mező 
minden olyan esetben értéket kap, amikor a naplóüzenet nem strukturált formájú. A hálózati (ssl, 
tcp, udp) és a fájl modulok támogatják a bináris átviteli módot. Ezáltal elkerülhető, hogy a mezőket 
valamilyen (pl. CSV) konverzió segítségével kelljen megőriznünk. A mezőkre a dollár ($) jellel tu- 
dunk hivatkozni az nxlog nyelvből. Minden modul támogatja az Exec direktívát. Az ebben megadott 
kifejezést az nxlog a modulon áthaladó minden naplóüzenet esetén kiértékeli és végrehajtja. 

Most lássunk egy példát, amelyben az nxlog nyelvi eszközeivel a logot mezőkre bontva, majd 
ezeket vizsgálva képesek vagyunk bonyolultabb feldolgozásra is. A feladat az Apache access.log 
naplójának szétválogatása úgy, hogy a kliens, illetve szerver oldali hibák naplói két külön fájlba 
kerüljenek. Ezt úgy tudjuk megtenni, hogy a HTTP 400 és 500-as kódtartományhoz tartozó üzeneteit 
szétválogatjuk az alábbi konfigurációs állományban látható módszerrel: 


<Input access log: 
Module im file 
File ' /var/log/apache2/access.log’ 
Exec if $raw event =~ /^(\S+) (\5+) (\5+) \[([^\11+)\1 \" (\5$+) (.+) 
НТТР.\а\.\а\" (\а+) (\5+) e тг АА у \" AAEN ТЕУ МУЛ 


{ 
Hostname = $1; \ 
f $3 != "-" $AccountName = $3; \ 
EventTime = parsedate ($4); \ 


Т 


ТТРМеёһоа = $5; \ 

ТТРОКІ = $6; \ 

TTPResponseStatus = іпёедег ($7); \ 
FileSize = 58; \ 

TTPReferer = $9; \ 

ТТРОѕегАдепё = $10; \ 








ме УР ЧУР "О ЧЕ ЗУ ч АЛЕТ ЯЛ 27 
Т 


</Input> 


<Output client_error> 

Module om_file 

File ' /var/log/apache2/client_error.log’ 

Exec if ($HTTPResponseStatus < 400) ог ($HTTPResponseStatus >= 500) drop (); 
</Output> 


<Output server error: 
Module om file 


File ' /var/log/apache2/server_error.log’ 
Exec if ($HTTPResponseStatus < 500) drop(); 
</Output> 


<Route apache> 
Path access_log => client_error, server_error 
</Route> 


Az Apache access .log állományát soronként beolvastatjuk, majd egy reguláris kifejezés se- 
gítségével mezőkre bontjuk. A Perlhez hasonló szintaktikával ($+sorszám) tudunk a reguláris ki- 
fejezésben zárójelezéssel meghivatkozott substring értékét kiolvasni. Két kimenetünk van, ezekben 
eldobjuk azokat az üzeneteket, amelyek nem az odaillő HTTP válaszkódot tartalmazzák. 

Az nxlog-processor nevű bináris egy hasznos eszköz lehet az olyan egyszeri feldolgozásnál, mint 


amilyen az előző példában bemutatott access .log szétválogatása, amennyiben a már meglévő lo- 
got kell feldolgozni. Ez főként fájl alapú input esetén használható jól. Az nxlog-processor a beme- 
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netről addig olvas, amíg az el nem fogy, majd ezután kilép. Így tehát az nxlog-tól eltérő módon nem 
daemon-ként fut amely állandóan figyeli a bemenetet. 

Használata a fenti konfig esetén ilyen egyszerű: 
nxlog-processor -c apachefilter.conf 


8. Összefoglaló 


Az пх1ор egy olyan naplózó eszköz, amely segítségével több platformon tudunk logot gyűjteni, to- 
vábbítani és tárolni. Az apache stílusú konfigurációs formátumával és egyszerűen használható saját 
nyelvével egy olyan nyílt forráskódú eszközt kapunk, amely megpróbálja megteremteni az átjárha- 
tóságot a különféle formátumok és protokollok között. Ezáltal lehetővé teszi, hogy open- source 
alapokon heterogén környezetben központosított naplózást valósítsunk meg vagy bármilyen más fel- 
dolgozást végezzünk a naplókon. Bemutattunk néhány példát a használatára, azonban sok fontos 
funkciójáról nem tudtunk szót ejteni, mint például a korrelációs elemzések, riasztások, naplófájl 
rotálás, mintaillesztéses adatbázis stb. 

Amennyiben az előadás után megválaszolatlan kérdés merülne fel, vagy a dokumentációból nem 
világos valami, akkor kérlek írjatok az info@nxlog . org címre. Javaslatokat és ötleteket is szívesen 
fogadok. 
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А rendszergazda barát Linux 


A Linux, amit egy Windows szakember is imádni fog 


Czakó Krisztián 


Kivonat 


Ha Linuxról van szó, ritkán hallok semleges véleményt. Vannak a , Linux hívők", akik magasz- 
talják — és hajlamosak a rossz tulajdonságairól elfelejtkezni — és vannak a , Linux utálók", akik 
csak az utóbbit emelik ki. A , hívők" érveit nem részletezném, pár főbb kiragadásával most meg- 
elégszem: megbízhatóság, függetlenség a szoftvergyártóktól, nulla licencköltség, nagyfokú rugal- 
masság és skálázhatóság. Az ellentábor véleménye persze nem ez. Két dolgot emelnek ki minden 
alkalommal, ha Linux kiszolgálóról van szó. Az egyik következik a másikból. Szerintük a Linux 
kiszolgáló bonyolult, nehezen kezelhető, így a bekerülési költsége (az a bizonyos TCO, tehát az 
egyszeri és üzemeltetési költségek együttvéve) sokkal magasabb, mint az alternatív, kereskedelmi 
rendszereké, melyek kezelése egyszerűbb. 

Nem a fenti véleményekkel szeretnék most vitába szállni. Őszintén szólva többé- kevésbé 
egyetértek velük. Sokkal inkább egy olyan Linuxot szeretnék bemutatni, ami rendelkezik az is- 
mert pozitív tulajdonságokkal és frappáns választ ad a vele szemben felhozott kifogásokra. Egy 
Linux szerver, amit pofon egyszerű telepíteni, beállítani és üzemeltetni. Annyira, hogy ha egy 
alapvető hálózati rendszergazdai ismeretekkel rendelkező (pl. Windows) szakembernek adjuk a 
kezébe, további tanulás és utánajárás nélkül azonnal teljes és kiválóan működő rendszert tud vele 
építeni. 


Tartalomjegyzék 


1. Но! kezdődött? 
1.1. Miért tetszik nekem? .... 0...0... 


2. Mit tud a Zentyal? 
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2.4. A motorháztető alatt, bővíthetőség ........................... 


3. Csatlakozz te is, és részesülj a Zentyal adta új lehetőségekből! 
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1 HOL KEZDŐDÖTT? 





1. Hol kezdődött? 


Amikor először találkoztam a Zentyal rendszerrel (leánykori nevén eBox Platform) megijesztett. 
Megijesztett, mert én is sokáig abból éltem, hogy értek a Linuxhoz míg mások nem. És a Linux 
TCO még így is jobb volt (na tessék, mégis vitatkozok a fentiekkel. . . ), hát sokan megfizették a 
szakértelmet, cserébe jobb, összességében olcsóbb rendszert kaptak. A dolgok azonban megváltoz- 
tak, de erről majd később. 


Szóval megijedtem, mert azt láttam ebben a rendszer- 
ben, hogy , elveszi a munkám". Kicsit ipari forradalom 
érzetem lehetne, ha a bármi valós fogalmam lenne róla, p EN EZEN] | 
hogy mit éreztek а munkások az ipari forradalom idején У ши 
a gépekkel szemben. Aztán elgondolkoztam а dolgon, és 
arra kellett rájönnöm, hogy hülyeség a gépeket okolni. In- 
kább örülni kell az új lehetőségeknek (nyilván a munká- 
sok nem örültek a megnövekedett szabadidőnek, így a Li- 
nux rendszergazdától sem várható ez el, ha ez egyben a 
jövedelem arányos csökkenését is jelenti). De ha őszin- 
tén belegondolok abba, mit is vesz ez el tőlem, nem érzek 
nagy hiányt. A , hagyományos" Linux rendszerépítésben 
пет nagy kihívás ugyan azt az öt sort bemásolni az smb . conf-ba és a slapd.conf-ba. Ráadásul 
az esetek 9990-ban két szó kivételével pont ugyanazt. А hosztnév és az egyik , dc—" kivételével pont 
ugyanazt. Ha kicsit lustábbak vagyunk, akkor még ez sem különbözik. 























MOOM ао зара 


1.1. Miért tetszik nekem? 


A géprombolás tehát elvetve, már csak azért is, mert szoftvert nehezebb eredményesen rombolni 
mint fizikai gépeket. Nem maradt más, mint megbarátkozni az újjal és megnézni mi benne a jó. Az 
első ami egy Linuxosnak szimpatikus, hogy a Zentyal nyílt forrású. A második (ez már nem min- 
den Linuxosnak lesz szimpatikus), hogy Ubuntu LTS-re épül. Azonban lássuk be, napjainkban új 
disztribúciót fejleszteni nagy merészség, de legalábbis komoly kihívás. Ezt a Zentyal fejlesztői is 
belátták és választottak. Sok lehetőségük nem volt. Ha nem kereskedelmi alapot keresünk, akkor a 
CentOS, Debian, Ubuntu hármasból lehet választani. Nem ismerve a döntés hátterét ebből a három- 
ból az Ubuntu cseppet sem rossz választás. Én a CentOS-t a RHEL alapjai miatt vetném el (nincs 
önálló fejlesztés, a RHEL pedig egy önállóan is vállalati szegmenst célzó rendszer), a Debiant a 
bizonytalan kiadási ciklusok és a rövid távú támogatottság (új kiadás + 1 év az előző verzióra, de ki 
tudja ez mikor lesz?) miatt vetném el. Marad az Ubuntu, ami technológiailag sokat épít a Debianra, 
de garantált kiadási ciklusaival és a hosszú távú támogatással az egyes kiadások esetén (LTS szerver 
verzióknál 5 év) megfelelő alapnak tűnik egy vállalati szerver megoldáshoz. 


A harmadik, és számomra legalább ennyire, ha nem még inkább fontos részlet az, hogy az egész 
megoldás szépen illeszkedik az Ubuntuba. Minden komponense önálló csomag (.deb) és minden 
egy önálló tárolóból (PPA) telepíthető. Nincs gányolás (make install vagy tar.gz kicsomagolás — 
sajnos sok ilyen megoldást láttam már), nincs egyedi csomagletöltögetés. Minden telepíthető apt-get 
segítségével is, ha épp úgy esik jól. Az én lelkivilágomnak mindenesetre jólesik, hogy ez a rész 
rendben van. Ugyanis ez az alapja annak, hogy egy rendszer stabilan üzemeltethető legyen. 


Ha végül megnézem, hogyan fordíthatom a hasznomra azt, ami elsőre rémisztően hatott (az egész 


rendszer faék egyszerűségét) arra jutok, hogy végre valaki automatizálta és leegyszerűsítette azt a 
rutinmunkát, amit mi Linux szakemberek már — valljuk be — unalmasan, rutinból csinálunk. 
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1.2. Miért jó a Linuxnak? 


Itt visszakanyarodnék az , ellentábor" fő érveihez: „а Linux bonyolult, a Linux szakemberek drágák 
és ezért a Linux megoldás TCO-ja valójában sokkal magasabb, mint a kereskedelmi megoldásoké" . 
A Zentyal esetén valami egész mással találjuk szembe magunkat. Egyszerű, átgondolt és integrált 
rendszert kapunk. A teljes beüzemelés és később az üzemeltetése egyszerűbb, mint egy Windows 
Small Business Server esetében. Megtartva a szabad szoftverek , árelőnyét" megszerzi az egyszerű 
bevezetés és üzemeltetés adta előnyt is. 


1.3. Miért jó a vevőnek? 


A Linuxot kedvelőket sosem kellett meggyőzni a rendszer előnyeiről. A piacon azonban a vevők 
igen jelentős többsége nem Linux kedvelő. Igazából még csak IT kedvelőnek sem mondanám őket, 
hiszen csak a bajuk van vele. Bonyolult, drága és nem értik a működését. Azt többnyire értik, hogy 
ez hogyan segít nekik (írógép helyett szövegszerkesztő, Magyar Posta helyett e-mail stb.), de elég 
sok bosszúságot is okoz. Kicsit elkanyarodva, pont ezt ismerte fel Steve Jobs és erre adott olyan 
választ, amivel az Apple ma ott tart ahol. 

Visszatérve saját témánkhoz, a vevőt egyetlen dolog érdekli: a saját haszna. Ez így puritánul 
hangzik, de ettől még igaz. Egy cég azért vásárol meg bármit, mert azt elvárja tőle, hogy az a profitját 
növelni fogja. Teheti ezt a költségeinek lefaragásával (pl. olcsóbb rendszer vásárlásával) vagy a 
bevételeinek növelésével. Így vagy úgy az egyetlen dolog ami számít az a profit. Ha a Windows 
rendszer olcsóbb, működik (és már csak mi emlékszünk a "90-es évekre, amikor nem működött), 
akkor azt fogja választani. Tehát vagy olyat adunk, ami olcsóbb, vagy olyat adunk ami sokkal többet 
nyújt ugyan azon az áron. A Zentyalban az a szép, hogy egyszerre képes mindkettőre. 

A Zentyal azért ideális egy vállalatnak, mert alacsony bekerülési költsége mellett (ingyenes szoft- 
ver, olcsó telepítés, alacsony fenntartási költségek hosszú távon) magas szolgáltatás mennyiséget és 
minőséget kínál. 


2. Mit tud a Zentyal? 


Erre a kérdésre nehezebb válaszolni, mint gondolnád. Attól függ ugyanis, hogy ki kérdezi. Ha a 
vevőd kérdezi, akkor lehetőséget ad a költségcsökkentésre és a hatékonyság növelésére egy időben. 
Erről az előbb írtam. Ha egy IT szolgáltatás értékesítésével foglalkozó kérdezi, akkor új lehetőséget 
ad több olyan új ügyfél elérésére, akik eddig az alternatívák ára vagy tudása miatt nem vásároltak 
tőle. Vagy más megközelítésben, ha a meglévő ügyfeleinek ezentúl MS SBS helyett Zentyalt kínál, 
akkor többet tud adni olcsóbban úgy, hogy saját árrését közben növeli. Mutass egy vállalkozást, aki 
nem erről álmodik! 

Ha informatikus kérdezi, akkor újabb két választ lehet adni. Linux szakembernek azt mondom, 
hogy lehetőséget a Linux eljuttatására oda, ahová eddig a bonyolultsága miatt nem sikerült eljuttatni. 
Lehetőséget arra, hogy kevesebb munkával több rendszert tudjon üzemeltetni. A szakmai tudása (a 
Linux belső rejtelmeinek megértése, ismerete) nem válik ezzel feleslegessé. Mindössze nem lesz rá 
nap mint nap szüksége. 

Azoknak a szakembereknek, akik eddig nem dolgoztak Linuxszal, új lehetőséget nyújt. Szá- 
mukra is megnyitja a nyílt rendszerek világát egyszerűségével anélkül, hogy hatalmas befektetésre 
lenne szükségük egy új rendszer — egy másik világnézet — megtanulására, megértésére. 

A továbbiakban az utóbbi két tábornak mutatom be a Zentyalt. Először a funkciókat, a beállítás 
egyszerűségét, a végén a technikai részleteket a Linux , szakiknak". 
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2.1. А Zentyal telepítése 


A telepítés legegyszerűbb módja, ha leöltöd a telepítő CD-t a http: //zentyal.org/downloads 
címről. Itt találsz 32 és 64 bites változatot is. Én mai modern PC-ken a 64 bitest javaslom. Ha szereted 
a kihívásokat választhatod a telepítés alternatív módját is: az Ubuntu legfrissebb LTS kiadásából a 
szerver változatot kell telepítened. A telepítés után hozzá kell adnod a Zentyal PPA-t és telepítened 
kell a Zentyal alapcsomagot! 

sudo apt-get install -y 
python-software-properties 

sudo add-apt-repository ppa:zentyal/2.2 

sudo apt-get update 


Z entyal sudo apt-get install zentyal 


Az eredmény mindkét esetben többé-kevésbé ugyanaz 
lesz. A Zentyal telepítőben van pár változtatás az ere- 
deti Ubuntu LTS telepítőhöz képest, így lesznek eltéré- 
sek. 
Ezek egyike sem olyan, ami egy Linux-os szak- 
embert zavarna, de ha nem vagy az, inkább ma- 
radj a Zentyal saját telepítőjénél. 
A , gyári" telepítő a Zentyal alapcsomagon kívül feltesz 
egy egyszerű grafikus felületet és a Firefox böngészőt. Az 
újraindítás után automatikusan bejelentkezik és elindítjaa ЕТТЕР 
böngészőt, mely azonnal a Zentyal bejelentkező felületét ыш ои ошын ösze асыл сш Н 
nyitja. A további újraindítások során már az automatikus 
bejelentkezés elmarad, szükséged lesz a telepítéskor meg- 
adott felhasználónévre és jelszóra. Ha magad telepítetted O Ő 
Ubuntu LTS-ből indulva, a grafikus felület nem lesz ott еы = 
automatikusan. Mindkét esetben igaz lesz viszont, hogy Zasa stanes ty пилашшыз 
a szervered IP címén (vagy ha van DNS, akkor a nevén) 
https-sel eléred а kezelőfelületét, így a konzolra már nem 
lesz szükséged. A továbbiakban nem lesz eltérés a két te- "0" 18 m= ü 
lepítési módszer között. 

Készítettem egy részletes videó tananyagot a Zentyal 
telepítéséről, melyet megnézhetsz a http://zentyal.hu/ oldalon. A videóban lépésről lépésre 
megmutatom, hogyan érdemes a rendszert telepíteni. 





















2.2. Integrált rendszer 


A Zentyalba bekerült minden olyan szolgáltatás, mely egy vállalati szervertől elvárható. Nyilvánva- 
lóan ez a Linux adta lehetőségek egy töredékét jelenti csak. Ez természetes velejárója az egyszerűsí- 
tésnek. Nem korlát igazából, hiszen minden funkciót, amit egy , mezei" Ubuntu LTS szerveren meg 
tudunk valósítani, itt is elérünk ugyanúgy: parancssorból, kézzel (apt-get) telepítve. 

Ami viszont bekerült, az teljesen integrálva lett a rendszerbe. Felejtsük el a kézi hegesztést, és 
a bonyolult beállításokat szolgáltatásonként. Az alap példánknál maradva, a Zenytalban a felhasz- 





!Ha virtuális környezetben telepítetted a Zentyal kiszolgálót, a telepítést követően az első teendőd a virtualizációs környe- 
zet kiegészítőinek telepítése legyen VirtualBoxban: 
sudo apt-get install linux-headers-server virtualbox-ose-guest-utils 
VmWareben: 
sudo apt-get install open-vm-toolbox 
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nálók kezelését LDAP címtárban oldották meg. Ez azt jelenti, hogy az OpenLDAP integrálva van 
a rendszerbe: ennek beállításaival minimálisan— akkor is csak haladó módban (ott beállíthatjuk a 
DN-t) - találkozunk. Egyszerűen megy. Az ehhez kapcsolódó funkciók (samba, dovecot, zarafa stb.) 
a telepítés után automatikusan megkapják az ehhez szükséges beállításokat. Ezzel nincs dolgunk és 
nem is találkozunk ezzel a felületen. Egyszóval nem kell minden egyes komponenst kézzel állítgatni, 
hogy működjön telepítés után. Feltesszük és megy. 

A felhasználó kezelés területén három módban tudjuk használni a rendszert: az egyszerű és a 
mester mód ugyanazt jelenti: önálló kiszolgáló saját LDAP szerverrel és felhasználókkal, amihez 
később további Zentyal kiszolgálókat kapcsolhatunk szolga (slave) módban. A szolga mód kivá- 
lasztásával meg kell adnunk a mester kiszolgáló elérhetőségeit (ezt a mesteren az LDAP menüben 
megnézhetjük). Ezután a szinkronizáció elindul. A mesteren pedig nyomon követhetjük a szolga 
rendszerek állapotát. 

A harmadik variáció egy érdekes, de mindenképpen hasznos 

megoldás. A Zentyal képes Microsoft Active Directory rendszerhez 

иЕе kapcsolódni és onnan venni а felhasználói adatokat anélkül, hogy 

i Е ehhez Кегрегоѕі kellene telepíteni és beállítani. Ehhez пет kell mást 

tennünk, mint a Zentyal AD komponenst feltelepíteni az AD mester 

kiszolgálóra, felvenni ott egy szinkronizációs felhasználót és beállí- 

tani a komponenst. Az ott megadott adatokat és az AD címét meg- 

adjuk a Zentyal kiszolgálónknak és a felhasználók (jelszavaikkal 
együtt) szinkronizálva lesznek. 





Ha a meglévő AD kiszolgálót szeretnénk kiváltani a Zentyallal, 
a Zentyal Migration Tool eszközkészlet áll rendelkezésünkre. En- 
nek két összetevője van: az egyik az a Windowson futó szoftver, 
mely képes exportálni a Windows Server beállításait (jelenleg Win- 
dows Server 2003 és 2008 verziókat támogat), valamint a Linux 
oldali megfelelője, mely az exportált adatokat importálni tudja. A 
Zentyal része egy teljes csoportunka szoftver is (a Zarafa, erről ké- 
sőbb lesz szó), mely szintén rendelkezik az Exchange szerveren (és 
Outlook PST fájlokban) tárolt levelek migrálásának lehetőségével. 
Ezzel együtt egy teljes eszköztár áll a rendelkezésünkre, mely segít- 
ségével egyszerűen és gyorsan válthatjuk ki régi, drága és megunt 
Windows szerverünket. 




















2.3. Funkciók 


Fájlszerver, tartományvezérlő 


Lássuk a Zentyal adta funkciókat. A rendszer alapját képező felhasználó kezelésről (LDAP, AD) volt 
szó az imént. Természetesen megtaláljuk benne a jól bevált Linux kiszolgáló szoftvereket. A fájlszer- 
ver és tartományvezérlő a samba. Annyit változtattak rajta, hogy alap telepítésben képes Windows 
7 munkaállomásokat tartományba léptetni (a Windows 7 registry módosítása nélkül), beletették a 
valós idejű vírusellenőrzést (ClamAV-al) és a szemetes (RecycleBin) funkciót. Ezek természetesen 
megosztásonként ki- és bekapcsolhatók. A megosztások kezelését leegyszerűsítették. Mindent ott 
érünk el a kezelőfelületen, ahol logikus, azaz nincs külön , Fájlszerver" rész. Ha csoportnak akarunk 
megosztást készíteni, akkor a csoport jellemzőinél kell ezt megtennünk. Ha felhasználónak akkor ott. 
Ha olyan megosztást szeretnénk, aminél a jogokat külön be akarjuk tudni állítani, arra van egy külön 
menü. Adhatunk hozzáférést felhasználóknak és csoportoknak, ahogy a sambában ezt megszokhat- 
tuk. 
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Levelezés, csoportmunka 


A levelezésért is a megszokott komponensek felelnek. A levelek fogadását és elküldését a Postfix 
végzi. Természetesen ennek a beállításai is a kezelőfelületről érhetők el, ahogy az integrált SPAM 
és vírusszűrésé is, melyekért az Amavis-ng, SpamAssassin és ClamAV hármas felel. A beérkezett 
levelek két helyre kerülhetnek. Ha , mezei" levelező rendszert készítünk, akkor a leveleink Maildir 
formában a fájlrendszerben kerülnek tárolásra, ahonnan a Dovecot szolgálja ki IMAP és POP3 pro- 
tokollal. Természetesen bekapcsolható az SSL illetve STARTTLS is, amihez a rendszer részeként 
elérhető tanúsítvány- kiadót tudjuk segítségül hívni, ha nem akarunk kézzel hitelesíteni. A webmail 
sem hiányzik, erre a RoundCube áll a rendelkezésünkre, ami mögött egy Apache webszerver teljesít 
szolgálatot. Mondanom sem kell, hogy minden integráltan, és minden a kezelőfelületről állítható. 
Sem a parancssor, sem olyan extra tudást igénylő beállítások nem kerülnek elő, mely egy Linuxot 
még nem kellően ismerő rendszergazda számára nehézséget okozna. Ilyen probléma egyszerűen 
nincs. 


Ha nem elégednénk meg a világ egyik legjobb levelező szerver környezetével, akkor leválthatjuk 
azt egy csoportmunka szoftverre. Erre a célra a nyílt forrású Zarafa kapott helyet a rendszerünkben. 
A Postfix/Amavis-ng/SpamAssassin/ClamAV csapat marad, csak a Dovecot/RoundCube részt cse- 
réljük le. Pontosabban nem is kell lecserélni, mert virtuális tartományonként beállíthatjuk, hogy ki 
használja a Dovecotot és ki a Zarafát. 

A Zarafa egy komplett csoportmunka megoldás. Tökéletesen alkalmas egy Exchange kiváltására. 
Rendelkezik minden szükséges funkcióval: levelezés, megosztható naptár, címjegyzék, teendők és 
jegyzetek. Nem hiányzik belőle az ActiveSync támogatás sem, így szinkronban tarthatjuk az adatain- 
kat kedvenc okostelefonunkkal is. Amint korábban említettem, kapunk hozzá egy migrációs segéd- 
programot is, mely képes Exchange kiszolgálóról vagy tömeges Outlook PST fájlokból átemelni az 
adatokat. A Zarafa saját webes felülettel rendelkezik, mely rendkívüli mértékben emlékezteti a fel- 
használóz az Outlook Web Access (OWA) felületére. Ez sem lesz akadály a váltásnál. Természetesen 
kapunk IMAP és POP3 kiszolgálót is, így a megszokott levelezőprogramjainkat nem kell lecserélni. 
A naptárhoz pedig szabványos iCal és CalDAV felületen is hozzáférünk kívülről. 

Ezek a nyílt forrású Zarafa részei. Ha Exchange kiváltására akarjuk használni meg kell emlé- 
keznünk egy kereskedelmi komponensről is. Ez pedig az Outlook MAPI támogatás, melyhez két 
külön, zárt forrású szoftverre van szükségünk. Az egyik a Zarafa kiszolgálóhoz kell, melyet ingyene- 
sen telepíthetünk (a Zentyal telepíti automatikusan) hozzá. Az ingyenes változat három párhuzamos 
Outlook klienst képes kiszolgálni MAPI-val. Ha ezen felül több munkaállomáson is szeretnénk Out- 
lookot használni, meg kell vennünk legalább a Zarafa Small Business Edition licencét. Ezt (Zentyal 
esetében) a Zentyal forgalmazóknál tehetjük meg a legegyszerűbben. Aki ismeri az Exchange li- 
cencköltségeit most üljön le. A Zarafa Small Business változatának licencköltsége mindössze nettó 
80€/5 felhasználó/év. Ez Egy Exchange licencnek a töredéke. Cserébe folyamatosan a legfrissebb 
Zarafa verziót használhatjuk és kapunk extraként egy külön mentő szoftvert hozzá, mely segítségé- 
vel a visszaállításokat gyorsan és felhasználónként, azon belül mappánként végezhetjük el szükség 
esetén. 

A Zarafa — főleg sok párhuzamosan dolgozó felhasználóval — jelentősen növeli a Zentyal hard- 
verigényét, ami a kezelőfelület miatt eleve nagyobb, mint az ugyanarra képes csupasz Linux. Egy 
Zentyal szerverhez Zarafa nélkül 2 GB memória kell a gyors működéshez, Zarafával ezt minimum 
meg kell dupláznunk, de nagyobb felhasználószámnál a 8 GB is szükséges lehet. Ennek a fő oka, 
hogy a Zarafa MySQL adatbázisból dolgozik, melynek mint tudjuk (optimalizálva is) sokkal na- 
gyobb a memóriaigénye mint az ext4 fájlrendszernek (Maildirben tárol levelek és adatok). Mind- 
ezekkel együtt is a Zentyalnak és a Zarafának a memóriaigénye messze elmarad egy Microsoft Win- 
dows Server és az Exchange igényeitől, azaz nem csak a licenceken, de a hardver költségeinken is 
faraghatunk. Arról az , apróságról" nem is beszélve, hogy ez nem OEM licenc, így ha szervert cseré- 


38 


2.3 Funkciók 





lünk vihetjük magunkkal, nem kell újra megvenni (vagy nem kell eleve többszörös áron nem OEM 
licencet venni). 


Hálózati infrastruktúra kezelése, hálózatvédelem, IDS, QoS, Proxy 


Hétköznapi alapfunkciókról van szó, azaz az IP címek kiosztásáról (DHCP), a névfeloldás biztosí- 
tásáról (DNS) és az idő szinkronizálásáról (NTP). Ezekre sorra az ISC DHCP és BIND kiszolgálóit 
valamint az alap NTP kiszolgálót kapjuk. Az érdekesség itt is az integrációban rejlik. 

A kezelőfelületről vehetjük fel a domaineket a DNS kiszolgálóba és az IP tartományokat a 
DHCP-be. Ez eddig nem nagy kunszt. Az érdekesség ott kezdődik, hogy ha а DHCP esetén beállít- 
juk а DNS automatikus frissítését, akkor a DNS oldal beállítása automatikusan megtörténik (direkt 
és fordított feloldáshoz is). Ha mindemellett a web kiszolgáló funkciót is használni akarjuk, és annak 
beállításánál felveszünk egy új DNS domaint, a DNS kiszolgálónkba automatikusan bekerül. Nem 
kell két helyen beállítani ugyanazt. 

Ugyanez az integráltság jellemző a tűzfal részre is. Alap telepítéssel is egy beállított tűzfalat 
kapunk, mely csak a szükséges funkciókhoz enged hozzáférést (a belső hálózatról is!). Ezen felül ha 
két csatolónk van, és az egyiket külsőnek jelöljük, akkor a külsőn letiltja a bejövő forgalmat, a belső 
felől pedig beállítja a címfordítást. Jobb alapbeállítást kapunk, mint a legtöbb SOHO router esetén. 
Ha emellett felteszünk egy új szolgáltatást, annak használatához automatikusan kinyitja a megfelelő 
portokat a belső hálózat felől és beteszi a szolgáltatások listájába a megfelelő port beállításokat, hogy 
ha módosítani akarunk ne nekünk kelljen keresgélni milyen portokat is kell kinyitni vagy bezárni. 
Nagyon hasznos. 

Az alap Linux NetFilter tűzfalhoz kapunk Layer-7 támogatást is, előre elkészített mintákkal, így 
nem csak portokat adhatunk meg a szűrésnél, hanem protokollokat. Például tcp/80-as port helyett 
mondhatjuk, hogy a http forgalom. Ez sokkal általánosabb, mégis szigorúbb, hiszen így a 80-as 
porton sem mehet bármi, csak http. Alkalmazás szintű protokoll elemzést ne várjunk tőle, de az alap 
csomagszűrésnél sokkal fejlettebb megoldás. 

A tűzfal beállításához, mint az az előzőekből igazából már kiderült objektumokat és szolgálta- 
tásokat tudunk használni. Azaz a hálózati címeket ( egyenként is) és tartományokat objektumokba 
rendezhetjük (akár többet is egybe) és ezen objektumokhoz rendelhetünk szabályokat. A szabályok- 
ban pedig nem portokat, hanem szolgáltatásokat adhatunk meg, ahol a szolgáltatásokba tudjuk fel- 
sorolni az oda tartozó portokat illetve protokollokat (Layer-7). A végeredménye egy átlátható, me- 
nedzselhető tűzfal lesz. A biztonságunkról ezen felül a Snort IDS gondoskodik, melyet csatolónként 
állíthatunk, ahogy azt is, mire figyeljen és mire ne. 

Nem maradt ki a Оо$ sem. A szolgáltatásminőség garantálására a Linux kernel Оо$ rendszerét 
kapjuk természetesen. Ebben az esetben is ember számára emészthető formában, egyszerű beállítha- 
tósággal. Csatolónkként, portra és protokollra szabályozhatjuk a sebességeket és a prioritást. 

A rendszer képes kezelni a többirányú Internet kapcsolatot is. Pár kattintással beállíthatjuk a ter- 
helés elosztását vagy hiba esetén az elsődleges irány váltását is valamint azt hogy miképp ellenőrizze 
a kapcsolatot (pl. átjárónak ping csomagok küldése). Aki próbált már ilyet Linux alatt az iproute-al 
beállítani az tudja értékelni, ha ezt pár kattintással el lehet végezni. 

Kapunk egy proxy-cache szervert is (Sguid), mely nem csak a böngészési élmény javítására 
alkalmas, hanem a Dansguardian segítségével a forgalom szűrésére is. Bekapcsolhatjuk a tartalom 
vírusszűrését (itt is a ClamAV fog szűrni) valamint beállíthatjuk a rendszer szűrési szigorúságát a tar- 
talomra is. Ezt a nagyon megengedőtől a nagyon szigorúig öt fokozatban kapcsolhatjuk, ami mellett 
egyedi szabályokat vagy az Internetről letölthető szabálygyűjteményt tudunk használni. Lehetősé- 
günk van a böngészési sávszélesség szabályozására is, mely a Sguid erre a célra fejlesztett funkcióját 
használja. Érdemes vele , játszani", mert nagymértékben tudja javítani a böngészési élményt terhelt 
vagy szűk sávszélességű vonalon. 
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Készíthetünk több szűrőprofilt is, melyeket aztán objektum vagy csoport- házirendhez kapcsol- 
hatunk. Az objektum-házirendek a hálózati objektumok (azaz IP címek vagy tartományok) alapján 
állítja be a megfelelő profilt, míg a csoport-házirend az egyes felhasználói csoportokhoz rendeli azt. 
Ez utóbbi működéséhez be kell kapcsolnunk a felhasználó azonosítást is a proxynál, és ki kell kap- 
csolni a transzparens módot, hogy az azonosítás működjön. Egyéb esetekben a transzparens mód a 
kényelmesebb. 


Távoli elérés, VPN 


Az aktuális Zentyal verzió három VPN technológiát nyújt a rendszer és a hálózat elérésére illetve 
két Zentyal szerver (és a mögöttük lévő hálózatok) összekapcsolására. A méltán népszerű OpenVPN 
régi ismerős, már a korábbi kiadásokban is megtalálható volt. Ennek használatához szükségünk van 
egy saját hitelesítés szolgáltatóra (CA), mely a felhasználóinkat és a szervert is hitelesíti, hogy az 
férjen csak hozzá a rendszerhez, akit mi szeretnénk. Szerencsére a Zentyalban erre is van megoldás. 
A CA létrehozása pár kattintás, a szervezetünk neve, az országkód, a helység, a megye és a lejárati 
napok számának megadásával azonnal elkészül a cégünk saját belső használatra szánt tanúsítvány 
hitelesítője. Ennek birtokában elkezdhetjük felvenni és beállítani az OpenVPN hozzáféréseket. Elő- 
ször egy új VPN kiszolgálót kell létrehozni, majd azt beállítani. Ezt követően lehet tanúsítványokat 
készíteni a felhasználóinknak. A Zentyal nagyon ötletesen lehetővé teszi, hogy kész , VPN csoma- 
got" töltsünk le, amit a felhasználónak odaadhatunk. Itt választhatunk Windows, Linux, Mac-OS és 
két Zentyal szerver összekötésére használható csomag között. Windows esetén az OpenVPN telepí- 
tőt is betehetjük a csomagba a beállítások és a tanúsítványok mellé. 

Az IPSec támogatás a jelenlegi változatban még csak az osztott kulcsos hitelesítést támogatja, 
elsősorban két hálózat összekötésének céljából, amikor a túloldal szabványos IPSecet vár el. Ennek 
beállítása is egyszerű, az IP címek, a tartományok és az osztott kulcs megadása után működik a 
csatorna. 

Windows felhasználók számára lehet kényelmes a PPTP támogatás, bár én ezt nem szoktam 
javasolni a megoldás ismert problémái miatt. Ha mégis szükség van rá, a beállítás itt 15 egyszerű. A 
VPN hálózat címtartományának (amiből a kliensek kapnak), a DNS és a WINS kiszolgáló címeinek 
megadásával a kiszolgáló kész. A bejelentkezéshez a biztonság érdekében itt külön felhasználókat 
kell felvegyünk, nem használhatjuk a központi azonosítást. Jobb is így. 


Kommunikációs szolgáltatások 


Itt két funkcióról érdemes szót ejteni. A szabványos XMPP üzenetküldő Jabber kiszolgáló is része 
a rendszernek, természetesen integrálva, így a bejelentkezéshez a rendszerben felvett felhasználói 
neveket és jelszavakat lehet használni. Külön érdekesség, hogy a belső felügyeleti rendszer is, ami 
monitorozza a szolgáltatásokat és erőforrásokat, képes XMPP-vel jelezni ha gondja van. Erre is 
használhatjuk a saját Jabber kiszolgálónkat (persze más XMPP szerverre is küldhetünk üzenetet). 

Emellett egy alap telefonközpont funkciót is kapunk, mely az Asterisk PBX rendszerre épül. 
Itt csak a telefonáláshoz tényleg nélkülözhetetlen funkciók lettek a kezelőfelületen implementálva, 
(még) nem említhető egy lapon mondjuk a Trixboxszal. Ami benne van, az viszont korrektül illeszke- 
dik a rendszerbe. Az alap beállításoknál felvehetünk egy külső szolgáltatót (szabványos SIP), amin 
keresztül a kimenő hívásokat intézhetjük és ahonnan a bejövő hívásokat fogadjuk. Emellett min- 
den felhasználónkhoz rendelhetünk egy melléket (ezt a felhasználó jellemzőinél). Támogatja még 
a konferenciabeszélgetést is: felvehetünk , konferenciatermeket", amibe a megfelelő teremszám és 
kód ismeretébe tudunk belépni (, kívülről" is, ha van külső SIP kapcsolatunk). VoIP (SIP) telefon- 
készülékek használatához beállíthatunk nekik melléket, jelszót, а hangposta számát és egy értesítési 
e-mail címet, ahová levelet küldhet a rendszer, ha üzenetünk érkezett. 
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2.4 A motorháztető alatt, bővíthetőség 





További hasznos holmik 


Van még pár funkció, amikre itt most csak az említés szintjén térek ki. Ilyen az FTP kiszolgáló (vs- 
ftpd, integrálva, ahogy kell), a , captive portal" (Wifi hotspotok mögé), a Radius szerver (vállalati 
Wifi hitelesítéshez), nyomtatómegosztás (CUPS), , felhasználói sarok" (a felhasználóink beléphet- 
nek és saját adataikat módosíthatják, ha van levelező szerverünk, akkor külső pop3 szerverről levél 
letöltést állíthatnak be) és virtualizáció (KVM alapú virtuális gépek létrehozása és menedzselése a 
Zentyal felületéről). 

Fontosnak érzem itt megemlíteni, hogy a Zentyal fejlesztése folyamatos és nagyon gyors. A 2010. 
nyarán megjelent 2.0 és a 2011. ősszel megjelent 2.2 közötti időben hatalmasat fejlődött. A kezelő- 
felület gyorsabb lett, a funkciók nagymértékben bővültek. A teljesség igénye nélkül az újdonságok 
listáján volt a virtualizáció, az IPSec és a PPTP VPN, a Captive Portal is. 


Mentés 


A végére hagytam a minden rendszer kihagyhatatlan részét jelentő mentő funkciót. A Zentyal esetén 
két mentési részről beszélhetünk. Az egyik a beállítások és felhasználók mentése. Ez kevés adat, 
de ez kell a rendszer helyreállításához, ha azt újra kell telepíteni. Ezt exportálhatjuk egy fájlba ma- 
gunknak, vagy az ingyenes felhő előfizetésünk segítségével tárolhatjuk központilag is. Utóbbiból a 
telepítéskor automatikusan helyreállíthatjuk a rendszerünket, vagy egy teljesen új kiszolgálót építhe- 
tünk egy alap beállításcsomagot felhasználva sokkal gyorsabban. 

A mentés lényegi része természetesen az adatok mentése. Itt a jól ismert duplicity mentő szoft- 
vert kapjuk. Fzt állíthatjuk be a kezelőfelületen. Használhatjuk helyi mentésre egy könyvtárba, vagy 
a helyi hálózaton rsync vagy FTP szerverre (e célra egy olcsó NAS kiváló megoldás lehet egy kisvál- 
lalatnál). De menthetünk a felhőbe is (Amazon, Zentyal cloud stb.). Utóbbi esetben a biztonságot a 
mentés titkosításával érhetjük el. A mentések időzíthetők, beállíthatjuk milyen gyakran kérünk teljes 
és milyen gyakran változás-mentést. A mentésekben kereshetünk és pár kattintással visszaállíthatjuk 
a hiányzó adatainkat. 


2.4. A motorháztető alatt, bővíthetőség 

Az elején említettem, hogy többek között azt szeretem a Zentyalban, hogy tisztán valósítja meg a 
funkcióit, illeszkedik az Ubuntu rendszerbe. Fontos azonban tudni, hogy ahhoz, hogy a rendszert 
kényelmesen, kellemes kezelőfelületről vezérelhessük kompromisszumokat kell kötnünk. Egy ilyen 
kompromisszum az, hogy a beállításokat (szöveges , konfig fájlok”) a rendszer felülírja. Ez — ha a 
megbízható működést tartjuk szem előtt — elengedhetetlen. На a normál (kezdő szintű) telepítést 
választottuk és az elején feltettük a komponenseket ez láthatatlanul megtörténik. Az alaptelepítéskor 
nem kiválasztott funkciók esetében azonban, az adott funkciót külön be kell kapcsolnunk, és ilyenkor 
egy listát kapunk azon beállítási fájlokról, amit felül fog írni. Itt aztán választhatunk, hogy akarjuk-e 
a Zentyal felületét az adott funkcióhoz használni vagy sem. Tiszta, egyértelmű megoldás. 

Az egyes beállító fájlok elkészítéséhez a rendszer sablonokat használ a háttérben. Ezen sablo- 
nokat módosíthatod, így elvégezhetsz kézzel is olyan változtatásokat, amiket a webes kezelőfelü- 
let nem tesz lehetővé. Arra figyelj, hogy ne az eredeti sablont írd át (azt szó nélkül felül fogja 
írni egy esetleges frissítés). A Zentyalban — nagyon bölcsen — erre is felkészültek. A sablonok a 
/usr/share/zentyal/stubs/modulneve/ mappákban találhatóak. A módosítandó sablont má- 
sold le a /etc/zentyal/stubs/ könyvtárba (korábbi verzióknál a zenytal helyett még ebox volt 
a mappanév!). Amit oda lemásoltál az felülbírálja az eredetit, de a frissítéskor nem cseréli le a rend- 
szer. Azzal számolj viszont, hogy ebben az esetben a sablon frissülése a gyári csomagban nem fog 
érvényesülni a változtatásod miatt. A stabil verzióban normálisan nem változnak a sablonok, de jobb 
odafigyelni erre. 
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3 CSATLAKOZZ ТЕ 15, ÉS RÉSZESÜLJ А ZENTYAL АРТА ÚJ LEHETŐSÉGEKBŐL! 





A sablonok módosításán kívül lehetőséged van egyedi szkripteket futtatni az egyes modulok 
beállításakor. Ezeket а /etc/zetyal/hooks/ könyvtárba kell tenned. A lehetőségről a Zentyal 
dokumentációjából és a Zentyal wikiben tudsz bővebben olvasni. 

A Zentyal nem akarja átvenni az uralmat a géped felett mindenáron. Bármely általa támogatott 
funkciót kikapcsolhatsz, és akkor azzal nem fog foglalkozni, a beállításokat nem fogja generálni. 
Ugyanígy feltelepíthetsz az Ubuntu szerverre más komponenseket is, amik nem ütik a rendszer 
működését és beállíthatod, kezelheted azokat a , hagyományos" módon. Azaz a Zentyal kiválóan 
együttél a meglévő rendszerrel is, szakember számára lehetővé téve annak bővítését, megőrizve a 
Linux sokrétűségét. Eközben egy nagyon egyszerű, könnyen használható eszközt ad azok kezébe, 
akik nem értenek (adott esetben nem is akarnak érteni) a Linuxhoz, csak egy megbízható vállalati 
kiszolgálóra vágynak. 

A Zentyal rendszerről magyarul találsz információkat a zentyal.hu oldalon. Fórummal, oktató- 
anyagokkal és tréningekkel igyekszünk segíteni a rendszer használatát. Amint azt a cikkben már 
említettem az oldalunkon találsz egy ingyenes telepítést oktató videót is. 2011. májusban az Ubuntu 
Developer Summit alkalmából Budapesten jártak a Zentyal fejlesztői is. Szerveztünk közösen egy 
szemináriumot, ahol Ignacio Correas (CEO) beszélt a rendszerről, Jorge Salamero Sanz bemutatta, 
hogyan használható a Zentyal Exchange kiváltására, én (Czakó Krisztián) pedig a Zentyal tűzfalként 
való használatát mutattam be. A szeminárium teljes felvételét is eléred a zentyal.hu oldalon. 


3. Csatlakozz te is, és részesülj a Zentyal adta új lehetőségekből! 


Azzal kezdtem a cikket, hogy bemutattam miért jó a Zentyal. Miért jó a Linuxnak, a végfelhasználó- 
nak. A Zentyal egy nagyon jó lehetőség azon informatikai vállalkozások számára is, akik egy jobb, 
olcsóbb alternatívát szeretnének kínálni ügyfeleiknek. Azoknak, akik több ügyfélre vágynak. 

A Zentyal nyílt forrású és teljesen ingyenes. Ha csak ezt kihasználod, máris hatalmas lehetősége- 
ket ragadsz meg. A Zentyalhoz kiegészítő szolgáltatásokat lehet vásárolni. Zentyal felhő előfizetést, 
ahol a szervereidet (vagy éppen az ügyfeleid szervereit) egy központi felületről menedzselheted, 
vagy éppen üzleti támogatást, hogy legyen biztosan szakember aki segít, ha valami nem úgy műkö- 
dik, ahogy szeretted volna. 

Ha érdekelnek ezek a lehetőségek, és szeretnél te is profitálni ebből a kiemelkedő minőségű 
rendszerből, keress minket, regisztrálj a zentyal.hu partner oldalán! Mi előadásokkal, tréingekkel és 
szakmai anyagokkal segítünk neked abban, hogy többet, jobbat nyújthass ügyfeleidnek. 
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syslog-ng web GUI-k 
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2 MIRE JÓ A KÖZPONTI LOG GYŰJTÉS? 





1. Mi a syslog? 


A Wikipedia definíciója szerint a syslog egy szabvány a programüzenetek gyűjtésére. Lehetővé teszi, 
hogy el lehessen különíteni az üzenetet generáló programot az üzeneteket gyűjtő és feldolgozó alkal- 
mazásoktól. Eredetileg a sendmail kiegészítőjének készült, de igen hamar rájöttek hogy ez sokkal 
általánosabban felhasználható. Így most már szinte minden operációs rendszer és hálózati eszköz 
támogatja a syslog használatát. Az eredeti megvalósítás fájlba és hálózatra tudta elküldeni az üzene- 
teket, az újabbak már adatbázisszervernek és még számtalan fogadó oldalnak képesek továbbítani 


őket. 


1.1. Miért syslog-ng? 


A syslog szabvány már nagyon sok éve velünk van, így számtalan alkalmazás született a megvalósí- 
tására. Ezek közül az egyik a syslog-ng. Hogy miért érdemes syslog-ng-t használni, ha egy átlagos 
Linux-disztribúcióban három különböző syslog megvalósítás is található? Csak néhány érv, fontos- 
sági sorrend nélkül: 


e gyorsaság, 


Р 


nagy teljesítmény, függetlenül а konfiguráció hosszától, szűrőktől stb. 


sokféle forrás és cél: fájl, socket, pipe, program, ТСР, UDP, titkosított (SSL), adatbázis (libdbi) 


patterndb: üzenetelemzés, akár korrelálás is 


e makrók, sablonok, amikkel az üzenetek könnyen formázhatóak, külön válogathatóak stb. 


áttekinthető, logikus konfiguráció, ami pl. lehetővé teszi, hogy ha egy komplex szűrési feltételt 
több helyen is használunk, akkor azt elég legyen egy helyen definiálni és a többi helyen csak 
hivatkozni rá 


minden kiadáshoz elérhető részletes, jól érthető dokumentáció 


rengeteg platform támogatása: Linux, "BSD, HP-UX, AIX, Solaris stb. 


, made in Hungary" 


Ezek közül önmagában bármelyik jelentős előny, de így kombinálva még inkább. 


2. Mire јб a központi log gyűjtés? 


A rendszerüzenetek központi gyűjtésének számtalan előnye van, kényelmi, praktikus, biztonsági és 
megfelelőségi is. 

Kezdjük a kényelemmel. Ha nincsen központi log gyűjtés, akkor ha bármilyen problémát érzéke- 
lünk, akkor kénytelenek vagyunk bejelentkezni az adott gépre, megkeresni, hogy az adott eseményről 
vajon hova képződnek a logok, majd elkezdeni keresgélni benne. Ha az esemény több gépet is érint, 
akkor ugyanezt végig kell játszani további gépeken is. Ehhez be kell jelentkezni több gépre is, tudni 
kell a jelszavakat, a könyvtárstruktúrát stb. Központi log gyűjtés esetén egy helyen kell keresgélni 
az eseményeket egységes struktúrában, amivel időt és energiát takaríthatunk meg. 

Az időt és energiát nem csak azzal takarítjuk meg, hogy kényelmesen hozzáférünk a logokhoz. 
Ha azt akarjuk megnézni, hogy mitől lassú az szerverünk, lehet, hogy már akkora a load, hogy 
percekig tart, amíg egyáltalán bejutunk a szerverre, majd a logok megjelenítése is nagyon lassan 
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2.1 Web GUI grep helyett?! 





megy. Vagy már be se jutunk, a konzolon sem. De központi loggolás esetén amíg az fsck-n dolgozik 
a gép, addig is már lehet keresni a hiba okát, mert a rendszernapló nem csak a vizsgált gépen található 
meg. 

És persze biztonsági okokból is jó, ha a logok nem csak helyben vannak meg, ha nem egy másik 
helyen is. Ha megtörnek egy gépet, akkor az egyik első teendő a logok törlése és / vagy manipulálása, 
a nyomok eltüntetése részeként. Sokat viszont nem ér a helyi ügyeskedés, ha a központi log gyűjtő 
szerveren már ott van, hogy honnan és hogyan jutott be a támadó. 

Ezzel eljutottunk a megfelelőséghez. A fentiek miatt nagyon sok szituációban a törvényi és egyéb 
szabályozások megkövetelik a központi log gyűjtést. Ilyenek például a PCI-DSS, COBIT vagy Ma- 
gyarországon a HPT. 


2.1. Web GUI grep helyett?! 


Amiket idáig elmondtam a központi naplózásról, az jó esetben kevés Linux-felhasználónak lesz 
újdonság. Akinek meg az, remélem hogy ezek alapján belátja, hogy érdemes így csinálni. Viszont 
az előadás címében nem a központi log gyűjtés, hanem web GUI szerepel, ami már a hard core 
linuxosoknál kiverheti a biztosítékot. Miért kéne mindenféle színes, szagos, szélesvásznú webes 
felületeket használni, ott vannak a hagyományos linuxos eszközök, a grep és az awk, a gnuplottal 
pedig még grafikont is lehet rajzolni. 

A grep, awk és társaik tényleg fantasztikus eszközök. De komplex kereséseknél vagy sok adatnál 
az SOL hátterű webes felületek sokkal gyorsabbak és hatékonyabbak. A bonyolult kereséseket pár 
egérkattintással össze lehet állítani, és ha tudjuk, hogy erre a későbbiekben is szükségünk lehet, 
akkor a legtöbb esetben a keresést el lehet menteni. 

Ha másodpercenként több ezer üzenetünk érkezik be, könnyű eljutni a sok millió soros logokhoz. 
Az adatbázisok indexei ilyenkor is lehetővé teszik a Google- szerű válasz időket, azaz sok milliós 
adatsorból bonyolult lekérdezésekre is a másodperc tört része alatt választ kapunk. Ugyanez grep- 
pel akár két nagyságrenddel is lassabb lehet, 0,15 helyett 10s jellegű lekérdezési időket mértem kb. 
5 000 000 üzenetnél. 

Összességében a web GUI-k egyszerűsítik és gyorsítják a munkát, azaz sokkal gyorsabban lehet 
egy probléma végére járni, mint ha nem használnánk őket. 


3.  Syslog-ng web GUI-k 


Most hogy már tudjuk, hogy miért érdemes a logjainkat központilag gyűjtenünk, és hogy webes 
felületen szeretnénk keresni bennük, ideje pár konkrét alkalmazást is megvizsgálni. Az elmúlt fél 
évben sok syslog-ng-n alapuló vagy syslog-ng-vel együtt működő alkalmazást kipróbáltam. Volt 
köztük a felhő szolgáltatásoktól kezdve az egyszerű php scripten át az extrém forgalomra felkészített 
rendszerekig minden. Ezekből emelem ki, amiket leginkább fontosnak éreztem, mutatom be röviden, 
sorolom fel előnyeit, hátrányait, ill. egy képernyőképpel is illusztrálom, hogy is néz ki. 


3.1. Loggly 


A Loggly egy felhő alapú szolgáltatás, azaz nincs szükség, hogy helyben bármilyen dedikált szer- 
vert telepítsen az ember. A használata nagyon egyszerű. Először is létre kell hozni egy felhasználói 
nevet a Loggly webes felületén. Bejelentkezés után egy varázsló megad minden információt ahhoz, 
hogy perceken belül már nézegethessük a beérkező logjainkat. Pár egérkattintás elég ahhoz, hogy 
a syslog-ng konfigurációba minimális módosítással bemásolható konfiguráció minta megjelenjen a 
képernyőn. Egyedül a log forrás átírására lehet szükségünk. 
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A Loggly üzleti alkalmazás, ahol az árazás függ a naponta beérkező üzenetek mennyiségétől és 
attól, hogy ezeket mennyi ideig szándékozzuk őrizgetni. A szolgáltatás bizonyos korlátok mellett 
ingyen is elérhető. Ezek szerencsére nem minőségi korlátok, azaz minden funkciója elérhető, de a 
napi maximális log mennyiség és a tárolási idő erősen limitált. Aki azonban csak egy-két kisebb 
gépet üzemeltet, valószínű jól el lesz ezekkel a korlátokkal is. 

A webes felület nagyon kényelmes, letisztult. És hogy a hard core linuxosok is otthonosan érez- 
zék magukat: parancssoros. Az első pár parancs összeállítása után már könnyen fog menni a lekér- 
dezések és grafikonok készítése. A parancsok ezek után már könnyen előhívhatóak a historyból is. 





Az elmúlt hetekben jelent meg egy új szolgáltatásuk is, az , Alert Birds", ami lehetővé teszi, 
hogy ha bizonyos keresési feltételeknek megfelelő logok érkeznek be, akkor erről az Alert Birds 
figyelmeztetést küldjön. Ez lehet e-mail, flash alkalmazás, különböző API-k stb. 

A Loggly ajánlható azoknak, akik új helyi rendszer üzembe helyezése nélkül gyorsan szeretné- 


мз, 


nek központi log gyűjtő megoldáshoz jutni. 


Előnyök: 
e nincs szükség helyi szerver üzemeltetésére 
e gyors és egyszerű használatba vétel 
e UNIX életérzés :-) 


e API a naplózáshoz, lekérdezéshez, konfiguráláshoz 


Hátrányok: 
e nem helyben van, azaz a hálózati kimaradások log vesztéshez vezethetnek 
e az Internet kapcsolat gyakran túl drága nagy mennyiségű log feltöltéséhez 


e a syslog üzenetek néhány része nem tárolódik, nem kereshető (pl. facility, severity) 


További információ a Loggly honlapján! érhető el. 





http: //www. loggly . com/ 
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3.2. További felhő szolgáltatások 


Az első kipróbálható felhős log szolgáltató a Loggly volt. Azóta továbbiak is megjelentek. Egyikük, 
a Logentries?, amelyiket kipróbáltam, és sok érdekes technológia található benne, többek között 
saját log küldő függvények a legfontosabb programnyelvekhez, platformokhoz, keretrendszerekhez. 
A másik a РарегТгай?, amelyiket még nem volt alkalmam kipróbálni. 


3.3. Loganalyzer 


A Loganalyzer egy egyszerű php alkalmazás, amely alkalmas a MySQL adatbázisba gyűjtött lo- 
gok böngészésére és keresésére. Eredetileg nem a syslog-ng-hez készült, de pár apróbb korláttal 
(nincs külön mező a programnévnek és a processzazonosítónak), alkalmas syslog-ng-ből érkező 1о- 
gok megjelenítésére is. Minthogy MySOL-t használ a logok tárolására és indexelésére is, így nem 
túl jól skálázódik. А MySOL-be az adatok egyszerű , insert"-tel kerülnek be, ami másodpercenként 
pár száz üzenetnél többre nem elég és pár millió üzenetnél már a keresés is elég lassú. 

A webes felület kicsit túlzsúfolt, rengeteg olyan információval, gombbal, adománygyűjtő linkkel 
stb. amikre a napi használatban nincs szükség, viszont a képernyő egy jelentős hányadát elfoglalják. 
De ha sikerült mindent jól beállítani és a képernyő közepére koncentrálni, akkor minimális syslog 
ismeretekkel és a dokumentáció bújása nélkül is könnyen használható. 











Source "My Syslog Source! :: Adiscon LogAnalyzer :: All Syslogmessages - Mozilla Firefox 
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A Loganalyzer egy egyszerű megoldás azoknak, akiknek nincs túl sok logja, és egy teljesen 
szabad webes felületen szeretne hozzáférni a logjaihoz. 


Előny: 


e egyszerű telepítés és webes konfiguráció 


Hátrány: 


e nem skálázódik 





-http://logentries .com/ 
https: //papertrailapp . com/ 
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e zsúfolt képernyő, sok hiba 


További információ a Loganalyzer honlapján! érhetőek el. 


3.4. Logstash 


A Logstash egy érdekes eszköz logok gyűjtésére, szűrésére és megjelenítésére. Sokféle forrásból, 
többek között a syslog-ng-től is tud logokat gyűjteni, különböző szűréseket, átalakításokat végezni 
rajtuk majd eltárolni egy adatbázisba és megjeleníteni webes felületen. A saját adatbázisán kívül 
még sok más kimenetre is el tudja juttatni a logokat. 

Bár még mindig egy 1.0-ás verziójú szoftver annak minden korlátjával, de mégis ez az egyik 
legkönnyebben beüzemelhető webes felület. Elég egy fájlt letölteni, minta alapján elkészíteni egy 
pár soros konfigurációt és már gyűjti is a logokat fájlból vagy mint egy központi syslog kiszolgáló. A 
webes felület egyszerű, de nagyon könnyen és hatékonyan használható, a keresési történetek hiánya 
ellenére is. 








MySQL helyett elasticsearch-öt használ, így sokkal jobban skálázódik, mint az egyszerű MySQL- 
es megoldások. Sok log esetén az adatbázis rész különválasztható akár külön gép(ek)re is, ami sokat 
segít a skálázódásban. Sajnos a log management még nem része a webes felületnek, így a régi logo- 
kat még csak az adatbázis-kiszolgáló közvetlen elérésével lehet kitakarítani. Ez azonban scriptekből 
könnyen automatizálható. 

A Logstash ajánlható azoknak, akik percek alatt szeretnének üzembe helyezni egy jól skálázható 


РЕ Р) 


rendszert és böngészni а logjaikat, таја később finomhangolni és bővíteni а rendszert. 


Előnyök: 


e egyszerű indulás, csak a sun-java a függősége 


e jól skálázódik 





thttp://loganalyzer.adiscon.com/ 
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3.5  Logzilla 





Hátrányok: 


e nincs log management, hozzáférés szabályozás, mentett keresések 


További információ a LogStash honlapján? 


3.5. Logzilla 


A Logzilla az egyik legrégebbi syslog-ng webfelület üzleti reinkarnációja, a php-syslog-ng-é. Felü- 
lete hasonlít az elődjére, de rengeteg új funkció belekerült. A felhasználói felület már támogatja a 
Cisco Mnemonics-ot, bővültek a grafikon készítési lehetőségek és már tud e-mail figyelmeztetése- 
ket is küldeni. A háttérben már van LDAP integráció, üzenet deduplikálás, és külső indexelés hogy 
a nagy adatbázisok is gyorsan kereshetőek legyenek. 








A Logzilla árazása rugalmas és sok szempontot figyelembe vesz. Így van pár kisebb korláttal ren- 
delkező, de ingyen elérhető változata is, ami kisebb, Cisco eszközöket is használó hálózatoknak jó 
hír. Elérhető virtuális gépként is, ami bekapcsolás után szinte azonnal használható, de ahol nagyobb 
forgalom várható, ott ajánlott inkább fizikai gépre telepíteni. Ez persze sokkal több lépést igényel, 
de így sokkal jobb skálázódás érhető el. 

A Logzilla ideális megoldás egy Cisco eszközökkel teli hálózati központba. 


Előnyök: 
e nagyon jó Cisco támogatás (Cisco alkalmazott fejleszti) 
e nagy mennyiségű üzenet feldolgozása az optimalizált MySQL elérésnek és a sphinx-nek kö- 
szönhetően 
Hátrányok: 


e fizikai gépre a telepítés nehézkes 


További információ a Logzilla honlapján" 





Shttp://logstash.net/ 
$http://www.logzilla.pro/ 
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3.6. SSB – Syslog-ng Store Вох 


Az SSB egy naplózó szerver, amely alkalmas log üzenetek gyűjtésére, osztályozására, rendszerezé- 
sére és biztonságos tárolására. Egyaránt alkalmas üzemeltetési és megfelelőségi (compliance) célok 
megvalósítására. Része a syslog-ng kereskedelmi változata, mely több mint negyven platformról 
tudja továbbítani a logokat az SSB-nek. A webes felületen részletesen beállíthatóak a különböző 
felhasználhatói szerepkörök és a hozzáférés a logokhoz. Az SSB, mint a syslog-ng fejlesztői által 
készített webes felület, képes a legjobban kihasználni a syslog-ng kínálta lehetőségeket. 














További információ az SSB honlapján”. 


3.7. ELSA: Enterprise Log Search and Archive 


Az ELSA (ami egy angol rövidítés és szójáték: log archiválás és keresés vállalatoknak), egy új 
központi naplózó rendszer, mely a syslog-ng-n és a patterndb-n alapul. Az első komolyabb fejlesztés 
a BalaBiten kívül, amelyik kihasználja a patterndb-ben rejlő lehetőségeket. Az adattárolás és keresés 
a MySQL-re és a sphinx-re épül, melyhez egy egyszerű, de nagyon jól használható web felület 
csatlakozik, mely villámgyors elérést biztosít üzenetek millióihoz is. 

Az ELSA új szoftver, még az 1.0-ás verziót sem érte el. Ennek velejárója, hogy szinte semmi 
dokumentáció nem elérhető, leginkább csak a Firefox támogatott, és azért van még mit finomítani 
rajta. Telepítése csak az Ubuntu 10.04-hez van leírva, de még oda is nehézkes. Jelenleg is folyik 
a következő verzió fejlesztése, ami szinte teljes újraírással jár, és remélhetőleg sokkal egyszerűbbé 
teszi a beüzemelést. 

Architekturálisan az ELSA fel van készítve a folyamatos magas üzenetszámra, és hogy akár 
órákon át ennek többszörösét is fogadni tudja csúcs terhelésnél. A hasonló megoldásokban használt 
reguláris kifejezések helyett az ELSA patterndb- t használ, mely gyorsabb, és sokkal alacsonyabb 
az erőforrásigénye. Így képes a logokból a hasznos információt kinyerni, még hasznosabbá téve a 
beérkező üzeneteket. Például megkülönbözteti keresésnél, hogy egy adott IP-cím forrása vagy célja 
egy adott eseménynek, és nem csak úgy általánosan az IP-címre keres rá. Jelenleg a rendszer néhány 
Cisco, HTTP és Windows kapcsolódású patternt tartalmaz és további patternekkel bővíteni nem túl 
egyszerű. A következő verzióval várhatóan ez is könnyebb lesz. 





Thttp://www.balabit.com/network-security/syslog-ng/log-server-appliance 
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3.7 ELSA: Enterprise Log Search and Archive 





A jobb skálázódás érdekében a webes felület, az adatbázis és az indexek külön gépekre is szét- 
szórhatóak. Így érhető el, hogy extrém mennyiségű log üzenet is Google-szerű válaszidővel keres- 


hető. 


ELSA - Mozilla Firefox 










































©] ]/ http://172.16.105.139/ ~ie] [eg al 
E Legtöbbször látog...v h нум  ммо @таһи ğ index FjosNewsv  ореп$Ш$Е Newsv » 
ELSA Lej М 
Queres» Admin v 
Enterprise Log Search and Archive 
Query [ classzSSH LOGIN | | _SubmitQuey | 
Start Time [2011-04-22 18:35:51 | Start | Add Term ЕЗ AND || МОТ | Group Ву | Мо Group Ву " 
[Епа Time | Епа | Add Term ” jse Index 
ssh2 (8) Х 
Result Options... ~ [Field Summary 
host) program(1) classé!) port(2) authmethod(1) user(1) device(i) земсе() 
Records: 2 / 2 1067 ms 1 15 у 
Timestamp a Fields 
тсе Accepted keyboard-interactive/pam for гоо! from 127.0.0.1 port 55390 ssh2 
nto Эд =172.18.105.1 =sshd =5SHMOGIN ро:=55390 -keyboard-interactíve pam 
14:09:40 : 
7.0.0.1 zssh2 
RE Accepted keyboard-interactive/pam for root trom 127.0.0.1 port 46096 ssh2 
Into y {#172.16. 105 zgshd =55НОШОбИН port 45096 =keyboard-interactive/pam 
141151 27 
jerzroot devcszz127 0.0.1 icezssh2 
Records: 2 / 2 1067 ms 1 15 v 
































Az ELSA használata ott ajánlott, ahol extrém mennyiségű log képződik, és így minden kezdeti 
nehézséggel együtt is megéri az ezt kezelni képes szoftverrel foglalkozni. A tervek szerint a konfe- 
rencia időpontjában már elérhető lesz egy új, sokkal könnyebben használatba vehető verzió. 


Előnyök: 


e Extrém skálázhatóság (15-20 kmsg/s folyamatos és 50-100 kmsg/s csúcs terhelés akár órákig) 


e patterndb, amely jobban skálázódik a regexpes megoldásoknál és valós időben kigyűjti a hasz- 


nos információt 


Hátrányok: 


e korai fejlesztési fázisban, dokumentáció nélkül 


További információ az ELSA honlapján? érhetőek el. 





Snttp://code.google . com/p/enterprise-10g-search-and-archive/ 
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2 ,ÚGY KEZDŐDÖTT, HOGY VISSZAÜTÖTT" 





1. Történeti előzmények 


A mobiltelefónia területén ismert módszer az iparjogvédelmi csatározás. Szinte minden jelentősebb 
konkurens hadilábon áll valakivel, az Apple többekkel is. Ezt már megszoktuk, de az, hogy a szaba- 
dalmi jogviták mellé kezd felzárkózni a design (formatervezési mintaoltalom, védjegy), az újdonság. 


2. , Úgy kezdődött, hogy visszaütött? 


2.1. Hadüzenet a tengeren túl 


A történeti fonalat 2011 tavaszán érdemes felvenni. Április közepén indította az Apple az első tá- 
madásokat az Amerikai Egyesült Államokban a Samsung! és a Google ellen. A Samsung elleni — 
mellékleteivel együtt 373 oldalas — kereset? szabadalmi, formatervezési és versenyjogi elemeket is 
tartalmazott. 


A kereset bevezetője szerint az Apple 2007-ben forradalmasította a telekommunikációs piacot az 
iPhone megjelenésével, amely többek között az érintőképernyő varázsát, a zenetárolási lehetőséget, 
az internetkapcsolatot illetve elegáns designt jelentette, és amely összetéveszthetetlen volt bármely 
más termékkel. 2007-ben felzárkózott mellé az iPod Touch és 2010-ben az iPad. 


2007-ben a Time Magazin az év legjobb technikai kütyüjévé (Gadgets) választotta az iPhone-t. 
2011 márciusára 108 millió iPhone került világszerte értékesítésre, iPodokból ez a szám meghaladja 
a 60 milliót, iPad esetében pedig a 19 milliót. További érdekesség, hogy az Apple reklámozási célra 
2 milliárd dollárt költött 2007 és 2010 között. A benyújtott keresetben hivatkozik az Apple a meg- 
sértett szabadalmak listája? mellett formatervezési oltalmakat érintő bejelentésekre (design patents 
és trade dress)! valamint az egyes ikonokhoz tartozó védjegyekre? is. A jogsértő termékek között 
nevesíti a kereset a Samsung Captivate, Continuum, Vibrant, Galaxy S 4G, Epic 4G, Indulge, Mes- 
merize, Showcase, Fascinate, Nexus S, Gem, Transform, Intercept, az Acclaim smart phoneokat és a 
Samsung, Galaxy Tab tableteket is. Különlegessége a pernek, hogy az elj@?rás részletes dokumen- 
tációja online" is olvasható. Az ügy jelen állása szerint éppen szabadalmi szakértők meghallgatására 
kerül sor” 





! Apple Inc. v. Samsung Electronics Co., 11-cv- 01846, U.S. District Court, Northern District of California (Oakland). 
http: //www . bloomberg . com/news/2011-04-18/apple-files-suit-against-samsung-over- 
galaxy-phones-and-tablets.html 

http: //www. apple . com/pr/pdf/110415samsungcomplaint . pdf 

37,812,828 (the "828 patent") Ellipse Fitting For Multi-Touch Surfaces, 7,669,134 (the “134 patent") Method and Appa- 
ratus For Displaying Information During An Instant Messaging Session, 6,493,002 (the “002 patent") Method and Apparatus 
for Displaying and Accessing Control and Status Information in a Computer System, 7,469,381 (the "381 patent") List Scrol- 
ling and Document Translation, Scaling and Rotation on a Touch-Screen Display, 7,844,915 (the “915 patent") Application 
Programming Interfaces for Scrolling Operations, 7,853,891 (the “891 patent") Method and Apparatus for Displaying a Win- 
dow for a User Interface. 7,863,533 (the “533 patent") Cantilevered Push Button Having Multiple Contacts and Fulcrums 

4D627,790 (the “790 patent”) Graphical User Interface For a Display Screen or Portion Thereof, D602,016 (the "D016 
patent") Electronic Device, D618,677 (the ""D677 patent") Electronic Device 

5U.S. Registration No. 3,886,196, U.S. Registration No. 3,889,642, U.S. Registration No. 3,886,200, U.S. Registration 
No. 3,889,685, U.S. Registration No. 3,886,169, U.S. Registration No. 3,886,197 

$http://dockets. justia.com/docket/california/candce/5:2011cv01846/239768/ 

Thttp://docs.justia.com/cases/federal/district-courts/california/ 
candce/5:2011cv01846/239768/332/ 
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2.2 Ellencsapás 





2.2.  Ellencsapás 


A válaszlépésre nem kellett sokáig várni, a Samsung is kereseti kérelmet nyújtott be, amely elsődle- 
gesen szabadalmi jogsértéseket nevesít. 

A közzétett kereseti kérelemből szintén érdekes adatokat lehet megismerni: A Samsung 2005 
és 2010 között 35 milliárd dollárt fordított kutatás-fejlesztésre és több, mint 50 000 kutató mérnököt 
foglalkoztatott 8700 telekommunikációs projektben. A Samsung szabadalmi portfóliója 2011. április 
1-jén 28 700 amerikai szabadalomból állt, amelyből 5 933 a telekommunikáció területére tartozott. 

1999-ben a Samsung jelent meg az okostelefonok első generációjával, amely egyesítette az 
internet-hozzáférés lehetőségét és a PDA funkciót. 2001-ben a Samsung PDA-ja (256 szín) nyerte a 
BusinessWeek , A legjobb termék" díját, illetve ezen évben állt elő először az ultraslim telefonnal, 
amely csak 9,8mm vastag volt. 

A keresetlevél miután kitér még több mobiltechnológiai fejlesztéssel kapcsolatos adatra, részle- 
tesen bemutatja a jogsértés alapjául szolgáló szabadalmakat? 


2.3. További frontvonalak 
Ausztrália 


Ausztráliában augusztusban nyújtott be keresetet az Apple, melyre reagálva a Samsung illetékesei 
azt nyilatkozták, hogy a Galaxy 10.1 Ausztráliában más formában kerül majd forgalomba, és így a 
formatervezési mintaoltalom megsértése fel sem merülhet!9. Az ausztrál bírósági tárgyalásról egy 
blogon!! tudósítottak , élőben", maga az eljárás meglehetősen nehézkes volt, tekintettel arra, hogy 
mindkét oldalon komoly érvek sorakoztak fel. Az ideiglenes intézkedést — amely keretében a for- 
galmazást betiltották — 2011. október 13-án hozta meg Bennett bírónő. Ezzel párhuzamosan 2011. 
szeptember 16-án a Samsung szintén keresetet nyújtott be az Apple еПеп!?. 


Japán 


Japánban! a Samsung áprilisban megindított eljárására válaszul augusztus 23-án szintén a Galaxy 
szériák (S, SID és a Tablet 7-es forgalmazásának betiltását kérte az Apple, arra hivatkozva, hogy 
mindezen termékek csak , szolgai másolatai" az iPhone, iPad termékeknek, ezen felül kártérítési 
igényét 100 millió jenben jelölte meg. Érdekessége az ügynek, hogy itt a bíróság szóvivője a folya- 
matban lévő eljárásról nem nyilatkozott. A 10.1-es Galaxy Tabok bevezetésére a per ellenére került 
sor. A forgalmazók nyilatkozata szerint a peres ügyet ezen a ponton nem tekintik a kereskedelmet 
akadályozónak. 





$http://www. ibtimes . com/articles/139288/20110428/samsung-vs-apple-complaint-for- 
patent-infringement-full-text.htm 

9U.S. Patent No. 7,675,941 ("the "941 patent"), U.S. Patent No. 7,362,867 ("the "867 patent"), U.S. Patent No. 7,447,516 
("the °516 patent"), U.S. Patent No. 7,200,792 ("the "792 patent"), U.S. Patent No. 7,386,001 ("the "001 patent"), U.S. Patent 
No. 7,050,410 ("the "410 patent"), U.S. Patent No. 6,928,604 ("the "604 patent"), U.S. Patent No. 6,292,179 ("the "179 
patent"), U.S. Patent No. 7,009,626 ("the "626 patent"), and U.S. Patent No. 7,069,055 ("the "055 patent") (collectively "the 
patents-in-suit") 

Vhttp://ausdroid.net/2011/08/02/samsung-australias-official-comment-on-apples- 
complaint-to-the-federal-court/ 

llhttp://blogs.wsj.com/korearealtime/2011/09/29/live-blogging-apple-and-samsungs- 
hearing/?mod=yahoo_hs 

lhttp://www.gizmodo.com.au/2011/10/apple-vs-samsung-the-injunction-stands/ 

Bhttp://www.reuters.com/article/2011/09/08/us-apple-samsung-idUSTRE7871HH20110908 
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Dél-Korea 


Dél-Koreában! is több szabadalom kapcsán állnak egymással perben a felek, jelenleg bizonyítási 
eljárások folynak. Az itteni eljárás következő érdemi fordulója 2011. november 25-én esedékes. 


Európai Unió 


Az Európai Unióban az első eljárások Németországban illetve Hollandiában indultak. Ennek oka 
egyszerű: a Németországban megindított eljárásból Hollandia azért marad ki, mert ott már koráb- 
ban nyújtott be az Apple ideiglenes intézkedés iránti kérelmet (az ottani jogrendből következően a 
dél-koreai alperesre vonatkozó eltérő szabályok miatt), és egy tagállamon belül párhuzamosan futó 
ügyekre nincsen lehetőség. 


Németország 


Jelen esetben két alperes van, a német székhelyű leányvállalat ellen értelemszerűen lehet a német 
bíróság előtt pert indítani, vele szemben el is lehet járni, a másikkal (koreai anyavállalat) kapcsolato- 
san egy kiegészítő szabály alkalmazása szükséges: , Ha az alperes . . . székhelye nem a tagállamokban 
van, vagy a tagállamok egyikében sem rendelkezik telephellyel, az eljárást a felperes lakóhelye vagy 
székhelye szerinti tagállam bírósága előtt kell megindítani. ..”!5 illetve kiegészítő szabályként azon 
tagállamok bíróságai előtt is, ahol a bitorlást elkövették, vagy megkísérelték. 

A beadvány többek között а Német Szövetségi Bíróság , Meghosszabbított limuzinok"!S esetére 
hivatkozik, amely értelmében bármely tagállamban megindított közösségi!" formatervezési mintaol- 
talommal kapcsolatos — jogsértés abbahagyására vonatkozó igényt — az egész Európai Unióra vonat- 
kozóan ki kell terjeszteni, tekintettel arra, hogy ha egy tagállamban jogsértő a cselekmény, fennáll a 
veszélye annak, hogy az EU más területén is az lesz. 

A német eljárásban az Apple kereseti kérelme online hozzáférhető!§, a Samsung reakcióját pedig 
a médiában felbukkanó hírekből lehet rekonstruálni. Hollandián kívül a többi tagállam a keresetle- 
vél szerint azért van , egy kalap alatt", mert a Rendelet 82. cikke a joghatóságot az alábbiak szerint 
állapítja meg: , keresetek és igények tárgyában az eljárást az alperes lakóhelye vagy székhelye sze- 
rinti tagállam bírósága előtt kell megindítani, vagy — ha az alperes a tagállamokban lakóhellyel vagy 
székhellyel nem rendelkezik — az alperes telephelye szerinti tagállamban". Alperesként pedig meg- 
jelölésre került a Samsung Gmbh és a Samsung Electronics Co. Ltd. Dél-Korea. A bíróság tárgyalás 
tartása nélkül — tekintettel a sürgősségi kérelemre, illetve az ideiglenes intézkedés szabályaira — el- 
rendelte a Galaxy Tab 10.1-esek forgalmazásának betiltását az EU-n (kivéve Hollandia) belül 2011. 
augusztus 9-én. A bíróság 2011. augusztus 16-án átmeneti jelleggel a forgalmazás korlátozását Né- 
metország területére szűkítette. 

A döntés megváltoztatásának okaként az derült ki, hogy az Apple beadványában — bizonyíték- 
ként szereplő — képek nem feleltek meg a valóságnak!’ 

A német ügyben eddig csak ideiglenes intézkedések születtek (a holland bíróság időközben meg- 
állapította, hogy a benyújtott formatervezési mintaoltalom az oltalom feltételeit nem teljesíti, így 





lhttp://fosspatents.blogspot .com/2011/09/apple-samsung-court-hearings-in-south.html 


1582. cikk (2) bek. 
16BGH GRUR 2010, 718, 722. Ват 56, 
http://juris.bundesgerichtshof.de/cgi-bin/rechtsprechung/document.py? 
Gericht=bgh&Art=en&az=I%20ZR%2089/08&nr=52206 

1786; a hangsúlyos elem, ha nemzeti mintaoltalmak lennének, minden tagállamban egyesével kellene lefolytatni az eljárá- 
sokat. 
http: //www.scribd.com/doc/61993811/ 
10-08-04-Apple-Motion-for-EU-Wide-Prel-Inj-Galaxy-Tab-10-1 

19A tabletek összehasonlítása: 
http://blog.webwereld.nl/wp-content/uploads/2011/08/Apples-Flawed-Evidence. jpg 
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az ezzel kapcsolatos kérelmeket elutasította, és a forgalmazás ideiglenes korlátozását csak szabada- 
lomra való hivatkozással helyezte kilátásba), abból viszont több is, hiszen a Galaxy Tab 10.1 mellett 
а 7.7-es Tabok forgalmazását is be kellett szüntetnie a cégnek? 


Hollandia 


A holland bíróság 2011. augusztus 24-én helyt adott az Apple azon ideiglenes intézkedés iránti 
kérelmének, amely keretében a Samsung Galaxy S, Galaxy SII és Ace típusú okos telefonokat mind- 
azon Európai országok vonatkozásában, ahol az EP 2059868 számon nyilvántartott (fotógalériával 
kapcsolatos) szabadalom érvényes?! . Egyes szakértők?? szerint viszont ezen szabadalom is tisztán 
szoftverszabadalomnak minősül, hiszen hardver oldalon nem tartalmazott feltalálói tevékenységet. 

A holland döntés értelmében szeptember közepéig kellett a Samsungnak megoldást találnia arra, 
hogy miként válthatja ki azt a szoftverrészt, amely a szabadalmat sérti. A holland döntés egyébként 
csak fél sikert jelentett az Apple részére, nem állt meg ugyanis e bíróság előtt a keresetnek a for- 
matervezéssel kapcsolatos ideiglenes intézkedés iránti igénye, ráadásul a bíróság — ahogy az később 
részletesen kifejtésre kerül — a , slide to unlock" szabadalom érvénytelenségét is megállapította. 

A Samsung szintén pert indított a 3G technológiával kapcsolatos szabadalma megsértése miatt, 
amelyet azonban a holland bíróság — a későbbiekben hivatkozott FRAND elv alapján első fokon 
elutasított”. 


3. Fegyverarzenál 


3.1. A Formaromboló 


Az Apple által előszeretettel hivatkozott egyik csodafegyver egy formatervezési minta, amely a jelen- 
leg is hatályos 6/2002/EK rendelet?! (a továbbiakban: Rendelet) alapján: „a termék egészének vagy 
részének megjelenése, amelyet magának a terméknek, illetve a díszítésének külső jellegzetességei — 
különösen a rajzolat, a körvonalak, a színek, az alak, a felület, illetve az anyagok jellegzetességei — 
eredményeznek”. A mintaoltalom feltétele, hogy az új és egyéni jellegű (tájékozott használóra eltérő 





Whttp://www.engadget . com/2011/09/04/ 
apple-wins-german-injunction-against-samsung-galaxy-tab-7-7-pul/ 
2Plhttp://worldwide.espacenet .com/publicationDetails/description? 
CC=EP&NR=2059868A2&KC=A2&FT=D&date=20090520&DB=&locale=en_EP 
Bhttp://fosspatents.blogspot .com/2011/08/dutch-court-orders-eu-wide-preliminary.html 
Bhttp://fosspatents.blogspot .com/2011/10/samsung-loses-dutch-case-against-apple.html 
Mhttp://eur-lex.europa.eu/LexUriServ/site/hu/consleg/2002/R/02002R0006-20040501-hu.pdf 
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összbenyomást tevő) legyen?. Az Apple 2004-ben tett bejelentését 2010 februárjában módosította, 
az oltalom azonosítószáma: No 000181607-0001. 
A hivatkozott rendelkezés tehát a rendelet 19. cikke, ami ezt mondja ki: 

„A lajstromozott közösségi formatervezésiminta-oltalom alapján a mintaoltalom jogosultjának 
kizárólagos joga van a minta hasznosítására és arra, hogy a mintát engedélye nélkül hasznosító har- 
madik személyekkel szemben fellépjen. Hasznosításnak minősül különösen annak a terméknek az 
előállítása, forgalomba hozatalra való felkínálása, forgalomba hozatala, behozatala, kivitele, hasz- 
nálata és e célokból való raktáron tartása, amelyre a mintát alkalmazzák, illetve amelyben a minta 
megtestesül." 

Ezek tények: 


1. Az Apple lajstromoztatta a formatervezési mintát. 
2. Megjelent egy új piaci szereplő egy hasonló termékkel. 


A per tehát arról szól, hogy elsődlegesen az Apple megpróbálja bebizonyítani, hogy a Samsung 
, bitorló". 

Természetesen sokféle módon lehet védekezni, a legcélszerűbb — és szerintem a Samsung által 
is választott út (bár ez a beadvány sajnos nem áll rendelkezésemre) — egy, a formatervezési mintaol- 
talom megsemmisítésére irányuló viszontkereset lenne. 

Megsemmisítési ok elég sok lehet, most csak a legjelentősebbre térnék ki, ez pedig a műszaki ren- 
deltetés által meghatározott formatervezési minta. Nem részesülhet ugyanis oltalomban az a külső 
jellegzetesség, amely kizárólag a termék műszaki rendeltetésének következménye?S. A formaterve- 
zési mintaoltalom természetesen grafikai illusztrációt tartalmaz, amelyet a beadványok több helyen 
idéznek is. Illetve a mintaoltalomból az Apple képviselői által kiemelt jellegzetességek?" többek 
között az alábbiak: 


1. egy négyszögletes termék, négy lekerekített sarokkal 
. egy sima, tiszta felszíni felület, amely a termék előoldalán található 


. egy látható fémkeret, amely a sima tiszta felszíni felületet határolja 


2 

3 

4. egy képernyő, amely a tiszta felszíni felület alatt központosítva található 

5. a tiszta felszíni felület alatt a képernyő egyértelmű, semleges lehatárolása minden oldalról 
6 


. ha a termék be van kapcsolva, színes ikonok jelennek meg a képernyőn. 


A fenti jellegzetességek mostanában már meglehetősen sok technikai eszközt körülírnak a mo- 
biltelefonoktól az e-book readereken át a tabletekig. 

Az Apple beadványa részletesen szemlélteti képek formájában a saját termékei, illetve az alperesi 
termékek hasonlóságait. Érdekes módon az egyik központi Кёреп?$ a Galaxy 10.1 sokkal jobban 
hasonlít az iPadra, mint a Galaxy 10.1-re. A PCWorld-on olvasható erről egy részletes elemzés” is. 
(Ehhez érdemes még megjegyezni, hogy a beadvány szerint sem a forma , kisebb változtatása", sem 
a név feltüntetése a tableten nem minősülhet , érdeminek", tekintettel arra, hogy az összbenyomás 
azonos.) 





25Rendelet 4. cikk (1) bek, és 6. cikk (1) bek. 
Rendelet 8. cikk 
"Ideiglenes intézkedés iránti kérelem (http ://www.scribd.com/doc/61993811/ 
10-08-04-Apple-Motion-for-EU-Wide-Prel-Inj-Galaxy-Tab-10-1) 15-16. oldal, 1.2. pont 
28Ideiglenes intézkedés iránti kérelem 24. oldal 
Dhttp://www.pcworld.com/article/238047/ 
apple offers flawed evidence in lawsuit against samsung.html 
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3.2. A Titkos Fegyverek 


A titkos fegyvertár részét természetesen a szabadalmak képezik. Az eddig említett eljárások során 
is már több megemlítésre került közülük, terjedelmi korlátok miatt azonban csak néhány lényegesre 
térünk ki. Az egyik az érintőképernyő több pontos érintésével kapcsolatos", a másik pedig az operá- 
ciós rendszer heurisztikus működési modelljét?! védi. A probléma hasonló a korábban ismert szoftver 
alapú szabadalmak problémáihoz. Az Amerikai Egyesült Államok lehetőséget ad az ilyen jellegű 
bejelentésekre, viszont az is előfordulhat, hogy a találmány vizsgálatakor — az oltalom megadását 
megelőzően — a technológia állását nem mérik fel elég alaposan. 


A holland bíróság például megállapította a „slide to unlock”?? szabadalomról, amely az Európai 
Unióban? szintén oltalmat kapott, hogy az valójában a technika állásához képest?" nem tartalmazott 
olyan mértékű újdonságot, amely az oltalomra alkalmassá tette volna. 


ОЗ 


Ekkor az Apple előállt a titkos fegyvernek számító , list scrolling and document translation, sca- 
ling, and rotation on a touch-screen display"? (a továbbiakban: 381-es szabadalom) című szabada- 
lommal. A szabadalom érdekessége, hogy a leírás maga egyszerű (Szakértői szemmel nézve talán túl 
egyszerű is. Itt arra utalok, hogy a LaunchTile & AppLens „one-handed thumb use” technológiák? 
már 2005-ben is ismertek voltak.), viszont tökéletesen alkalmas lehet arra, hogy az okostelefon-piac 
konkurenseit lebénítsa. Ha ugyanis az eljáró bíróságok sorra megállapítják, hogy a szabadalom ér- 
vényes, az Apple viszont — szemben a korábbi gyakorlattal — nem ad díjfizetés fejében hasznosítási 
jogot, hanem a konkurens termékek forgalmazásának betiltását kéri, egyeduralkodóvá válhat. 


A 381-es szabadalom érdekessége továbbá, hogy azt a Nokia már megkísérelte érvényteleníteni, 
azonban az általa megjelölt 20 pont egyike sem volt erre alkalmas. A Nokia vs Apple harci helyzetet 


legátláthatóbban talán Florian Müller foglalta össze". 


Az Apple egyébként ezt a csodafegyvert használja a Samsung ellen Amerikában és Ausztráliá- 
ban, valamint a HTC ellen indított eljárás egyik alapja is ez a szabadalom. 


Amire senki nem számított az az, hogy a Motorola pert nyer a mannheimi tartományi bíróság 
előtt, mert az Apple elmulasztja az első tárgyalást. Ez azt jelenti, hogy a bíróság a felek meghall- 
gatása és érdemi tárgyalás tartása nélkül a rendelkezésre álló dokumentumok alapján a keresetben 
foglaltaknak helyt ad. A magyar perjogban is ismert , bírósági meghagyás" azonban csak abban az 
esetben válik ítélet hatályúvá, ha az ellen az alperes 15 napon belül ellentmondással nem él. 





30 http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=14& 
0=$2Епеёаһіт1 $%2ЕРТОѕ$2Еѕгсһпит. ҺЕтаг=16 #=6861=50551=7, 663, 607.РМ.&05=РМ/7, 663, 607& 
-PN/7, 663,607 
Ihttp://patft.uspto.gov/netacgi/nph-Parser?Sect1-PTOláSect2-HITOFF§d-PALL§p—16 
Fnetahtml1%2FPTO%2Fsrchnum.htmár=1&f=G&1l=50&s1=7,479,949.PN.&O0OS=PN/7, 479, 949& 
RS=PN/7, 479,949 
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1& 
u=%2Fnetahtml%2FPTO%2Fsrchnum.htmár=1&f=G&1=50&s1=7657849.PN.&O0S=PN/7657849& 
=PN/ 7657849 
?http://worldwide.espacenet . com/publicationDetails/biblio? 
DB=EPODOC&adjacent=true&locale=en_EP&FT=D&date=20080903&CC=EP&NR=1964022A1&KC=A1 
34Neonode N1m bemutatása: 
http://www.youtube.com/watch?v=Tj-KS2kfIr0 2:53-tól а jobbról balra, balról jobbra mozdulatok ismertetése, 
a holland döntésről részletesebben: 
http://fosspatents.blogspot . com/2011/08/dutch-judge-considers-apples-slide-to.html 
BShttp://patft.uspto.gov/netacgi/nph-Parser?Sect1-PTOláSect2-HITOFF§d-PALL§p—-186 
2Епесаһїт1%2ЕРТО%2Езгсһпитш.һїт&г=1&Ё=Сб&1=50&з81=7,469,381.РЇЧ.&О$=РЇЇ/7,469,381& 
PN/7,469,381 
http: / /уійео.доос1е.сот/уійеор1іау?аӢосійӣ=-2417986546511555659 
http://fosspatents.blogspot .com/2011/06/apple-and-nokia-settle-patent-dispute.html, 
http://www.scribd.com/doc/52195210/NokiaVsApple-11-03-31-100 
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4. A FRAND-csel 


Természetesen a Samsung maga is hatalmas szabadalmi portfólióval rendelkezik, így aztán elég 
könnyen talált a mérnökök és ügyvédek lelkes csapata néhány szabadalmat, amely bizony az Apple 
iPhone S4 ellen felhasználhatónak tűnt. Az egyik ilyen a 3G (UMTS) technológiai standard. Ezen a 
jogalapon pert indított a Samsung Amerikában és Olaszországban, Franciaországban és ahogy arra 
már utaltunk, Hollandiában is. Azonban a viszontkereseteiben az Apple a FRAND (Fair, Reasonable, 
Non-discriminatory) eljárásra hivatkozva előadta, hogy a szabványok alapjait képező szabadalmak 
esetében forgalmazástól való eltiltásnak nincsen helye, és így legfeljebb díjigénnyel állhatna elő a 
Samsung, viszont a termék által használt szabadalmakra vonatkozóan a kapcsolódó díjakat az Apple 
beszállítói még megfizették" . 

Azt, hogy az egyes eljáró bíróságok miként ítélik meg a helyzetet, nem tudni. Mégis nagyon 
érdekes maga a helyzet, amelyben jelenleg úgy tűnik, hogy a kisebb (kényelmi funkcionalitásokra 
szorítkozó) szabadalmi portfólió többet jelent, mint az, amelyik a technológiai fejlődés alapját adja, 
utóbbit ugyanis — a technológiai fejlődés érdekében vállalt egyezmény miatt — , meg kell osztani". 

Nyilvánvalóan felmerülhetne itt is a szabadalmi kényszerengedélyek kérdése. A magyar szaba- 
dalmi törvény 32. §-a ugyanis kimondja, hogy: 


, Ha a szabadalmazott találmány másik szabadalom (a továbbiakban: gátló szabada- 
lom) megsértése nélkül nem hasznosítható, a függő szabadalom jogosultjának — kérel- 
mére – a gátló szabadalom hasznosítására a szükséges terjedelemben kényszerengedélyt 
kell adni, feltéve, hogy a gátló szabadalom szerinti találmányhoz viszonyítva a függő 
szabadalom szerinti találmány számottevő gazdasági jelentőségű műszaki előrelépést 
jelent. 


(2) A gátló szabadalom jogosultja — ha a szabadalmára az (1) bekezdés alapján kény- 
szerengedélyt adnak — a kényszerengedélyre vonatkozó közös szabályok szerint igényt 
tarthat arra, hogy méltányos feltételekkel engedélyt adjanak számára a függő szabada- 
lom szerinti találmány hasznosítására." 


E körben természetesen alapvető fontosságú a , számottevő gazdasági jelentőségű műszaki elő- 
relépés" fogalmának tisztázása, illetve a kényszerengedélyek esetén — az alap szabadalomra épülő 
technológia viszontjogosításának feltételei. 

A kényszerengedélyezés általános szabályai országonként eltérnek. Azonban — ahogy az Európai 
Unió korábban már rendeletbe foglalta a közegészségügyi problémákkal küzdő országokba törtnő ki- 
vitelre szánt gyógyszeripari termékek előállításával kapcsolatos szabadalmak kényszerengedélyezé- 
sének szabályait?’ — elképzelhető lenne egy — a technológiai fejlődést segítő kényszerengedélyezési 
rendszer kidolgozása. Talán épp ez a több tagállamot érintő háborúskodás elvezethet egy ilyen béke- 
kötési paktumhoz. Az mindenesetre biztos, hogy a Bizottság az üggyel foglalkozni kíván, ahogy ezt 
egy sajtóközleményben jelezte is". 

Itt kell azonban megjegyezni, hogy a szabadalmi kényszerengedélyek a formatervezési mintaol- 
talmakat nem érintik, hiszen a design nem kötelező elem, arra vonatkozóan a korábban már említett 
korlátozások vonatkoznak. 





Erről részletesebben itt: 
http: //fosspatents.blogspot .com/2011/07/apple-says-samsung-has-abusively.html 

39 Az Európai Parlament és a Tanács 816/2006/EK Rendelete: 
http://eur-lex.europa.eu/LexUriServ/site/hu/oj/2006/1 157/1 15720060609hu00010007.pdf 

40 „Тһе Commission has indeed sent requests for information to Apple and Samsung concerning the enforcement of 
standards-essential patents in the mobile telephony sector. Such reguests for information are standard procedure in antit- 
rust investigations to allow the Commission to establish the relevant facts in a case. We have no other comments at this 
stage" 
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5. Diplomáciai hadviselés 


Feltétlenül érdemes kitérni arra, hogy a háborút az Apple nem csak a Samsung ellen vívja, hanem 
csatában áll még a HTC-vel és a Motorolával (a kivásárlást követően ismertebb nevén: Google), 
valamint a Nokiával is"! . 

Természetesen a hadiállapot ennél jóval több, a mobiltelefónia és tabletek piacán érintett fél kö- 
zött is fennáll, mindenkinél különféle okokból. Ami azonban jól látható, hogy létezik egy androidos 
tábor (amit természetesen a Google erősít), és ők így egyben az Apple legnagyobb ellenfelei. 

A szövetségesek és ellenfelek felállása valami hasonló: 


MOBILE PATENT SUITS > == — 


Suing Suing each Licensed 
Patent-related suits between mobile other technology 
device/ component manufacturers 


to company 





Оџаісот/Мока (2005-08)  KodakiSamsung (2008-09) Apple/Kodak (2010-11)" 


Gamed Арріећока (2009-11)  KodaklLG (2008-09) 
“Kodak's separate suit against Apple will be decided on Aug 30. 
Source: Reuters, news reports (ZP REUTERS 


Hogy jön ide a diplomácia, tehetnénk fel a kérdést. Természetesen fehér kesztyűben. . . A Sam- 
sung legnagyobb megrendelője ugyanis továbbra is az Apple, ahogy az Apple részére az iparjog- 
védelmi eljárásokban érintett valamennyi készülék tartalmaz a Samsung által gyártott elemeket (pl. 
processzor, memória modul, lcd). Az eddigi eljárások alapján többek között az Apple jogdíjat fizet 
a Nokiának, а НТС és a Samsung a Mircosoftnak. 


6. Hidegháború 


Elnézve hát a csatatereket, a hadvezéreket és a fegyvereket, megállapíthatjuk, hogy bizony egy 
hosszabb háború vette most kezdetét. A frontvonalak folyamatosan átrendeződnek, az iparjogvé- 
delmi arzenál mellett felbukkannak versenyjogi elemek. Egy olyan háborúnak vagyunk tanúi, amely- 





АТА grafikon származási helye: http : //graphics . thomsonreuters . com/RNGS/2011/AUG/PATENT CI.jpg 


61 


6 HIDEGHÁBORÚ 





ről jogi egyetemre járó unokáink majd mint a híres , Apple— Samsung jogvita" fognak megemlé- 
Кели, és doktori értekezések és memoárok születnek majd mindkét oldalon. .. Egy azonban biztos: 
a fejlődés nem áll meg, mert most jött el az okostelefonok és tabletek kora. 
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Хеп{Л- Xen User Interface 


Hargitai Zsolt 


Kivonat 


Napjaink egyik kikerülhetetlen trendje a virtualizáció. A vállalatok és szervezetek, az egészen 
kicsiktől a nagyokig igyekeznek optimalizálni a rendelkezésre álló erőforrások kihasználtságát. 
Az egyik egyszerűen megérthető és gyors megtérüléssel kecsegtető terület a szerver hardverek 
számának minimalizálása virtualizáció alkalmazásával. 


Tartalomjegyzék 


1. 


2. 


A virtualizáció területe 
Nyílt forráskódú technológiák 


А XenUl termékről 
3.1. Eeégfontosabb funkciók ..... 0... 
3:25 "Térvezett fejlesztések: ma: а аа р а Н аый А иу 
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3 А XENUI TERMÉKRŐL 





1. A virtualizáció területe 


Amikor egy informatikai szakember a virtualizáció irányába akar elindulni, több út is kínálkozik 
számára. Több neves gyártó kínálja megoldásait: 


e VMware vSphere 
e Microsoft Hyper-V 


e Xen és KVM technológiák 


Mindegyiknek megvannak a maga előnyei és hátrányai, amíg a technikai oldalt nézzük; elis- 
merve, hogy a piacvezető VMware, menedzsment szolgáltatásait tekintve, jelenleg társai előtt jár. A 
technikai szempontokon kívül azonban még egy fontos tényezővel kell számolnunk, amely éppen 
az eredeti költségcsökkentési célunkat akadályozhatja: ez pedig a beruházásra fordítandó összeg. 
A gyártóközi megállapodásoknak vagy termékcsatolásnak köszönhetően néha ingyenesen juthatunk 
hozzá ezekhez a megoldásokhoz. A kivételektől eltekintve azonban általános érvényű szabály, hogy 
a fizikai gépek mennyiségének (vagy a bennük található processzorok/magok számának) növekedé- 
sével arányosan egyre több pénzt kell áldoznunk egy virtualizációs infrastruktúra megvalósítására 
és fenntartására. (Mellékesen а fenti , ingyenes"? megoldások esetén is szükségesek további fizetős 
komponensek egy jól működő architektúra kialakításához.) 


2. Nyílt forráskódú technológiák 


Azok számára, akik a fizetős megoldások helyett a nyílt forráskódú motorok irányába döntenek, alap- 
vetően két megoldás kínálkozik: a KVM és a Xen. Mindkettő támogat Windows és Linux vendég 
operációs rendszereket (ezen felül még számtalan egyéb OS-t is), mindkettőnek megvannak a maga 
kvantitatív előnyei a másikkal szemben (CPU és memória-kihasználtság vs. írási és olvasási sebes- 
ség), és szolgáltatásban, valamint támogatásban is hasonlóan erős háttérrel rendelkeznek, hiszen míg 
а KVM mögött a RedHat, addig a Xen mögött a Citrix és a Novell vonultat fel fejlesztői kapacitást 
és támogatást. A döntés tehát sok esetben egyedi érzelmi kötődésen vagy az elérhető tudáson mú- 
lik. A Novell hazai fejlesztőközpontja a Xen mellett tette le voksát, főleg mivel az nagy méretű 
szerverfarmok esetén jobb teljesítménymutatókat tudott elérni, mint vetélytársa, ezzel hatékonyabb 
kihasználtságot biztosított. 


3. А XenUI termékről 


Az elmúlt évek magyarországi virtualizációs projektjei során a Novell hazai fejlesztői az ügyfelek 
igényei alapján kezdtek el kidolgozni menedzsment felületet a Xen alapú virtuális gépek felügye- 
letére. Az eleinte még csak egy- két alapszolgáltatást biztosító fejlesztés mára XenUI néven külön 
termékké fejlődött. A termékfejlesztés fő célja, hogy elérhető árú, webes interfésszel rendelkező, 
nagy méretekben skálázható virtualizációs menedzsmentrendszert készítsünk a Xen motorhoz, főleg 
azokra az alapvető funkciókra koncentrálva, amelyeket a hazai nagyméretű szerverfarmok üzemel- 
tetői hasznosnak találnak. Azért szükséges külön kiemelni a , hazai" szót, mert bár itthon ezek a 
farmok a legnagyobbak közé tartoznak, nemzetközi viszonylatban csak a középmezőnybe sorolód- 
nak. Éppen ez adja a XenUI létjogosultságát, hiszen a gyártók által a hazai nagyméretű ügyfeleknek 
ajánlott megoldások gyakran feleslegesen sok és kihasználatlan funkciót tartalmaznak, amelyeknek 
fejlesztési és marketingköltségét ugyanúgy meg kell fizetni a termék árába építve. 
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3.1 Legfontosabb funkciók 





3.1. Legfontosabb funkciók 
Tekintsük át röviden a termék legfontosabb szolgáltatásait: 
e Vendég gépek létesítése, megsemmisítése, indítása és leállítása 
e Tetszőleges számú vendég és gazda operációs rendszer kezelése 
e Windows és Linux vendég operációs rendszerek párhuzamos kezelése 
e CPU, memória és HDD információk a vendég gépekről 
e Egyszerűbb riportok és grafikonok a hisztorikus futtatási adatokról 


e Jogosultságok és szerepek definiálása, valamint kiosztása 


3.2. Tervezett fejlesztések 
A termék fejlesztése jelenleg is folyik, és a közeljövőben az alábbi funkciók megvalósítása várható: 
e Vendég gépek migrálása gazda rendszerek között 
e Vendég gépek hardver elemeinek (CPU, memória, HDD) futtatás közbeni változtatása 
e Vendég gépek hálózati kártyáinak futtatás közbeni konfigurációja 
e Mobil felügyeleti alkalmazás fejlesztése 
e Vendég gépek csoportos kezelése 


e Csoportos jogosultságkezelés 
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Áttörni а falat 
(Szabad szoftverek egy önkormányzatban) 


Karay Tivadar 


Kivonat 


Budapest XVIII. kerülete, Pestszentlőrinc — Pestszentimre, Budapest déli széle, peremkerület. Nincs 
informatikai szempontból semmi különlegesség, nincs itt Infopark, nincs egyetem, nincs jelentős 
idegenforgalom. A sok lakos, a telkek, kertes házak, építkezések, no meg a szociális segélyek itt is, 
mint mindenütt, jelentős munkát adnak a Polgármesteri Hivatalnak. Kollégáink, az ügyintézők és 
hivatali alkalmazottak sem informatikai doktorátussal választották a köztisztviselői hivatást. Egy 
átlagos hivatal vagyunk, de ebben az átlagos környezetben nem átlagos az, hogy megpróbáljuk a 
, szokásos" informatika falát áttörni, és a szabad szoftvereket minél nagyobb arányban használni. 


Tartalomjegyzék 


1. 


Mekkora a fal? (Mik az akadályok?) 
1.1. Az államigazgatási informatika jellegzetességei .................... 
1.2. Kereskedelmi szoftverek: sinni sza plena e köze tk е жалы ж Жазы ы ызалы ШЗ 


Ki áll a fal elé? (Felhasználók és egyebek) 


Van-e kalapácsunk? (Milyen eszközeink vannak?) 
3.1. Vállalkozó segítségével ..... 0...0... 
3:2. Oktatás n Bassza о ишет Бе ДЬ АОЛ не Жр А УКУ р алй 


Lyukak а falon (Amit elértünk.) 

4T LEinüxkhensek илыш залзчезцр жу Ж жану ao a В A azok ЛЕСИ А АРЦ 
4.2. ОрепОййсе.огеТ4ыеобйсе............................... 
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Miért уап fal? (Mit tehetnek a magasabb szervek?) 
5.1. Ajánlások, szakmai segítség .............................. 


5.2. А jogalkotás lehetőségei ................................ 


Élet fal nélkül (Reménykedjünk...) 
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1 MEKKORA A FAL? (MIK AZ AKADÁLYOK?) 





1. Mekkora a fal? (Mik az akadályok?) 


1.1. Az államigazgatási informatika jellegzetességei 


Az államigazgatásiban az elvek, módszerek és az ezekhez kapcsolódó gyakorlatok nagyon lassan 
változnak. Mondhatnánk, II. József törvényei is meglátszanak a mai szokásokon. Ehhez a tempó- 
hoz képest berobbant a mindennapokba az informatika, és kezdett egyre több munkafolyamatban 
szerepet játszani. Ez a számítógéppel segített papír alapú ügyintézés korszaka, amely nagyon sok 
területen még ma is tart. Mit takar ez? 


e Az állampolgárok jellemzően papíron adják be kérvényüket, terjesztik a hivatal elé problémá- 
ikat. 


A hivatal papír alapon állít elő végzést,vagy határozatot. 


Az ügyek elbírálásához tartozó adatok, iratok (pl. társszervek igazolásai stb.) jellemzően szin- 
tén papíron érkeznek meg. 


e Az ügyek tárolása így alapvetően papíron, dossziékban történik. 


e Az informatika egyes (bár nagyszámú) mellékadatokat kezel (költségvetési, szociálissegély- 
adatok, térinformatika), amelyek végeredménye azonban papíron jelenik meg. 


e A számítógépet jórészt írógépnek tekintik, a töredékét használják ki a benne rejlő lehetőségek- 
nek. 


Sok kisebb-nagyobb, egymástól független szoftvert használunk. 


Az állampolgárokra vonatkozó adatok egységes adatbázisban történő tárolása nem valósult 
meg, jórészt törvényi akadályok miatt sem. 


Pedig az informatika sok területen más munkamódszert, 
más ügyvitelszervezést kívánna meg, illetve tesz lehetővé. 
A , számítógéppel segített" ügyintézés olyan, mintha a gép- 
kocsit arra használnánk fel, hogy húzzuk vele a szekeret. 
Nyilván több tekintetben előnyösebb, mint a ló, de maga az 
egész rendszer valahogy nem az igazi. 

Mitől alakult ez így? 

A papír alapú iratkezelés nagyon régi kialakult gyakor- 
lattal rendelkezik. A számítástechnika először egy-egy PC 
formájában jelent meg, segítő funkciókat látott el, nem volt 
se igény, se lehetőség arra, hogy az államigazgatási módsze- 
reket és gyakorlatot ne a papír alapú, hanem az informatika 
alapú lehetőségekhez kössük. A 2004. évi, azóta módosított 
„А közigazgatási hatósági eljárás és szolgáltatás általános szabályairól" szóló törvény (КЕТ) volt 
az első, amely egyes elemeiben megpróbált informatikai alapon új közigazgatási módszereket beve- 
zetni. Ez a törvény jelentősen módosult, még mielőtt a szemléletet megváltoztatta volna. Az informa- 
tika fejlődését az államigazgatásban jelentősen hátráltatta az elektronikus aláírás kontra ügyfélkapu 
háború, ami gyakorlatilag azt eredményezte, hogy az elektronikus aláírás rendszere csak nyomokban 
létezik, az ügyfélkapu pedig lassan fejlődött. 

Az államigazgatási informatika tekintetében az egyik ideális megoldás a hivatalok teljes műkö- 
dését lefedő integrált szoftver lehetne, ez azonban csak nagyon kevés helyen valósult meg, és még 
az eszméje sem terjed igazán. 
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1.2 Kereskedelmi szoftverek 





1.2. Kereskedelmi szoftverek 


Jól tudjuk, hogy az , állami pénz" laza elköltése mindig nagy kísértés az államigazgatás döntéshozói- 
nak. Az önkormányzatok és az államigazgatás felelős vezetői számára az informatika (épp a fentebb 
említett történelmi okok miatt) nem húzóágazat, hanem csak egy eszköz. Az eszközzel való törődést 
könnyű úgy gyorsan elintézni, hogy a rengeteg, hardvert és szoftvert kínáló vállalkozót megbízzuk 
egy-egy projekt elintézésével. , Le van a gond." Így aztán kialakult a rendkívül heterogén gép- és 
szoftverpark, fizetős szoftverekkel, amely szoftverek között kis, egyszemélyes cégek által gyártott 
célszoftverektől a közismert óriás alkalmazásaiig minden megtalálható. Az önkormányzati célalkal- 
mazások kizárólag kereskedelmi szoftverek, mivel alkotójuk szeretne hasznot realizálni rajta, az 
általános programok meg a , legelterjedtebb" kínálatából kerülnek elő. 

Ezek azok a tények, amelyek jelentős falat alkotnak az államigazgatásban a szabad szoftverek 
terjedése elé, és amely falat az informatikusok kötelességből nem, legfeljebb csak megszállottságból 
(mazochizmusból) próbálnak áttörni. 


2. Ki áll a fal elé? (Felhasználók és egyebek) 


Természetesen ilyenkor illenék jól leszidni a szerencsétlen felhasználókat, és kicsit óvatosabban, de 
távollétükben jól leszedni a keresztvizet a főnökökről is. 

Értsük meg őket, akkor sokkal könnyebben megy. 

Egy ügyintéző azt szeretné, ha mindennapi munkáját szép sorban, rutinból, feleslegesnek ítélt 
változások nélkül tudná végrehajtani. Épp elég baj neki a sok, nem mindig kulturált ügyfél, az állan- 
dóan (Magyarországon jellemzően sokszor) változó jogszabályi környezet, a négy évente, választá- 
sonként bekövetkező változások. Púp a hátára, hogy ehhez képest a számára érdektelen informatika 
túl gyorsan változik. , Miért nem lehet a régi jó Windowst használni" - kérdezik, de mi tudjuk, hogy 
igazából a 2000-es Word szövegszerkesztőre gondol, amit nem szeretne lecserélni. , Nem írok körle- 
velet, nem vagyok én informatikus." , Igaz, nem mentettem el a levelet, de megírtam, ott lesz a gépen, 
találjátok meg!" Ilyen és ehhez hasonló mondatokat gyakran hallanak a hivatalok informatikusai. 

Már azt is nehéz nekik megmagyarázni, hogy miért változnak időnként az alkalmazások. Mi- 
ért kötődik az (elromlott) géphez a régi szoftver, ha OEM licenceléssel lett vásárolva? Vagy egész 
egyszerűen, miért van másutt egy ikon, mint ahol eddig megszoktam? 

Bármennyire is furcsák informatikus szemmel ezek a felvetések, mégsem várhatjuk, hogy a hi- 
vatalnokok megértsék egy számukra idegen szakterület sajátosságait. 

Többször tapasztaltam, hogy egy, az ügyintéző munkáját könnyítő szoftverváltozást sem éltek 
meg fejlődésként, mert az átállás nehézségei, a betanítás-betanulás félelmei, a megváltozott munka- 
módszerekből adódó gyakorlatlanság elfeledtették a felhasználókkal, hogy tulajdonképpen pozitív 
változás történt. 

Természetes gyanakvás is van sok emberben. Miért akarjátok ezt a szoftvert? Miért pont nekem? 
Miért pont most? Egyszer – még korábbi munkahelyemen – MS Word helyett MS Worksot akartam 
bevezetni, ami jóval olcsóbb volt, és a feladatnak bőven megfelelt. Meggyanúsítottak, hogy nyilván 
rokonom a programozó. . . 

Lépten-nyomon előfordul, hogy egy szabad szoftver bevezetésénél (amely 99%-ig tudja mindazt, 
amit a korábbi), a felhasználó felismeri a hiányzó egy funkcionalitást (ami a munka szempontjából 
nem fontos, és amit egyedül ő használ), és közli hogy , Az egész rossz." (Persze nem egészen ilyen 
szalonképesen.) 

Az informatikus ebben a helyzetben köteles alkalmazkodni a valós igényekhez, és finoman el- 
terelni a figyelmet az értelmetlen igényekről, vagy a céltalan hőzöngésről. A logikus határig ki kell 
szolgálni az alkalmazókat, de meg kell tanítani nekik, hogy ez a szakma állandó változással jár, és 
ez nem rajtunk múlik. 
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3 VAN-E KALAPÁCSUNK? (MILYEN ESZKÖZEINK VANNAK?) 





Könnyebb a helyzet, ha a hivatal vezetői pártolják a 
munkánkat. Általában minden vezető örül a költségcsökken- 
МК Ше tésnek, amit а szabad szoftverek lehetővé tesznek. De ural- 
= csakAZ ЕМҮЁМЕТМЕ" kodik az a szemlélet is hogy „Csináljatok bármit, csak ne 
{ változzon semmi.", vagy , Nyugodtan cseréljétek le a szoft- 
vereket, csak az enyémet пе”. Ez utóbbi magatartás tud a leg- 
nagyobb gátjává lenni a fejlődésnek. Ha egy főnök belátja, 
hogy a változás szükséges és hasznos, akkor ne próbáljon 
a helyzetét kihasználva háttérben maradni. A harctéren is 
jobban hat az , Utánam!" vezényszó, mint az , Előre!" . 
Bármily meglepő, a nem szabad szoftverek gyártói nem állnak a fal elé. Ez is bizonyítja, hogy itt 
nem harc van, hanem egy értelmes feladat- és piacmegosztás. Sőt, egyre többen jelentkeznek olyan 
cégek, amelyek szabad szoftverekkel kapcsolatos szolgáltatásaikat ajánlják fel. 






3. Van-e kalapácsunk? (Milyen eszközeink vannak?) 


Az államigazgatás szempontjából szóba jöhető szabad szoftverek jók. A legtöbb helyen, ahol szabad 
szoftverrel kiváltunk egy kereskedelmit, nem csökken sem a minőség, sem a rendelkezésre állás, 
sem a biztonság. (Nem akarok belemenni abba az örökké dúló vitába, hogy a szabad szoftver, vagy 
a zárt a biztonságosabb, a jelenlévők nyilván elkötelezettek, a másik oldalon állók meg érdekeltek.) 

A szabad szoftvereket tehát nem kell megvédeni, megvédik ők magukat. Ezen a fórumon nem 
kell elmondani azokat az előnyöket, amelyeket mindenki tud a gyártófüggetlenségtől, a sok tesztelő 
által nyújtott biztonságon keresztül a változtathatóságig. 

Az államigazgatásban és az önkormányzati rendszerben fontos előnyöket emelném ki. A költ- 
ségek csökkentése mindig is fontos szempont volt, most válságos időszakban különösen. Ez akkor 
is igaz, ha egyesek kimutatni vélik, hogy az átállás nehézségei, az alkalmazott partnernek fizetett 
megbízási díj csökkentik a nominális hasznot. 


3.1. Vállalkozó segítségével 


Vegyük azt az esetet, hogy egy szabad szoftverre való átálláshoz külső vállalkozót veszünk igénybe. 
Gondoljunk bele: ha az országot elhagyó licencdíj helyett akár ugyanannyit is fizetünk egy helyi 
vállalkozónak, már az is haszon. A vállalkozó partnerré válik, belelát a munkánkba, alkalmazkodni 
tud a hivatali ügyintézés sajátosságaihoz, érdemben tud segíteni. A vállalkozó is tapasztalatot szerez, 
adott esetben képessé válik új, csak számunkra fontos megoldások, kiegészítések elkészítésére. A 
partner itt él velünk, egy országban, akár egy városban, akár potenciális ügyfél is lehet, véleménye, 
elképzelései állampolgári igényként számunkra is fontosak lehetnek (Arról nem beszélve, hogy a 
neki fizetett díj itthon adózik.). 

Ha másnak nem, az államigazgatásnak kellene élen járnia abban, hogy az ebben a körben felme- 
rülő problémákat hazai megoldásokkal oldjuk meg. Ha büszkék vagyunk a szabolcsi almára, a tokaji 
borra, és mozgalmak vannak a magyar áru védelmére, akkor az államigazgatásnak illene példát mu- 
tatnia a magyar programozói tudás hasznosításában is. 

Másrészt nem kell minden szabad szoftverre történő átálláshoz partnert igénybe venni. A szabad 
szoftverek nagy előnye a dokumentumok könnyű elérhetősége, a nyilvánosság, de legalább is renge- 
teg kolléga, szakember, támogató tud segítséget adni a hivatal informatikusainak. Ha egy új szoftver 
alkalmazását nem készen kapjuk, hanem magunk kísérletezzük ki, akkor lesz csak igazán a miénk, 
akkor tudjuk átlátni és kihasználni tulajdonságait, előnyeit. 
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3.2 Oktatás 





3.2. Oktatás 


A legfontosabb eszközünk az oktatás lehet, lehetne. A szabad szoftverek alkalmazásán kívül is az 
ügyintézők tudását időről-időre fel kell, kellene frissíteni. A törvényi változások, szoftver-verziócserék 
mind-mind módosítják a munkamódszereket, és az egykor jó szokások erodálódnak, vagy egyenesen 
hátrányossá válnak. Az ügyintéző nyilván hajlamos a számára legkönnyebb munkamódszert kialakí- 
tani, ez azonban a hivatal egésze szempontjából káros lehet. Ha a saját dokumentumait rendszeresen 
a saját gépére menti a kolléga, az számára kézenfekvő, de így más nem hasznosíthatja, továbbá egy 
merevlemezhiba esetén az egész eltűnik. 

Az oktatás így egyben minőségbiztosítási szerepet is ellát amellett, hogy nem egy pillanatnyi 
hiba okozta ideges állapotban, hanem nyugodt, tantermi körülmények között lehet elmondani a kol- 
légának, mit tud az új szoftver, miért van rá szükség, miért ezt választottuk, hogy kell használni. 
Lehet, hogy oktatóként , hazabeszélek", de minden oktatással, meggyőzéssel , elvesztegetett" mun- 
kaóra később többszörösen hasznosul a mindennapi munkában. 


4.  Lyukak a falon (Amit elértünk.) 


Nem a mi hivatalunk érte el a legjobb eredményt a szabad szoftverek alkalmazásában. Jelen szekció 
előadói között is ott vannak példaképeink, akiktől tanulunk, és szeretnénk tovább is tanulni. De azért 
elértünk valamit. 

15 szerverünkből 2 az, amin nem Linux fut, egyiken Novell fájlszerver (amit azóta ugyancsak 
lehetne Linuxon futtatni), a másik egy Windows 2000 szerver néhány régi alkalmazás kedvéért. 

Hogy kedvet adjak a Linux szerverekhez: A Novell NetWare rendszert manapság eleve Linuxra 
telepítik. Az Oracle adatbázis-kezelő, és minden más Oracle szoftver, beleértve a webszervert, alkal- 
mazáskiszolgálót, Application Expresst, remekül elfut Linuxon. Tűzfal, levelezőszerver általában az 
első, amit költségtakarékossági okokból mások is Linuxra telepítenek, és ezek nyilván szabad szoft- 
verek. A belső Apache alapú weblap, a JBoss alkalmazásszerver, a SguirrelMail webes levelező 
szabad szoftverek, és Linuxon futnak. A belső hibafigyelés Nagios szerver alkalmazásával történik. 

Ez persze nem nagy eredmény, sok más államigazgatási szervnél előfordul, hogy adatbázisszer- 
vert, webszervert, levelezőszervert stb. Linux szervereken futtatnak. 


4.1. Linux kliensek 


Mi pár éve elkezdtünk Linux klienseket is telepíteni. 270 
felhasználói gépből jelenleg több, mint harmincon valami- 
lyen Linux disztribúció fut. Több gépen is lehetne, de amíg 
egy régi gép fut a rajta levő OEM szoftverekkel, addig nem 
cseréljük le. A linuxos kliensek beilleszkedtek a hivatal éle- 
tébe. Sikerült megoldani néhány, az államigazgatásban köte- 
lező szoftver futtatását a Wine emulátorral. A platformfüg- 
getlen alkalmazások, köztük a hivatal számára legfontosabb 
iktató szoftver nyilvánvalóan működik Linuxon. A hibajaví- 
táshoz és felhasználótámogatáshoz szükséges távoli elérés 
is megvalósult. Megoldottuk, hogy előretelepített gépből 
klónozással , más operációs rendszerekhez képest" sokkal 
gyorsabban tudunk Linuxot telepíteni, a szükséges alkalma- 
zásokkal, a hivatalra és az informatikai rendszerre jellemző 
beállításokkal együtt. 
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4 LYUKAK A FALON (AMIT ELÉRTÜNK.) 





Természetesen ez a munka nem ment zökkenők nélkül. Máig sem értjük, hogy a hivatalban igen 
fontos Complex jogtár linuxos változatának fejlesztése miért állt le, pedig jól működő megoldás volt. 
Így Wine-nal kell üzemeltetnünk. 

Az önkormányzatok számára fontos és nehezen kikerülhető DOS-os program (ÖNKADÓ,) jól 
működik emuláció alatt. Azonban a róla történő nyomtatás szerver vezérelte hálózati nyomtatóra 
sokáig nem működött. Egy kollégám hónapokig kísérletezett vele, nyilván csak maradék időben. 
Sikerült, aztán külön gond lett az ékezetes karakterek helyes kezelése, végül az is megoldódott. 
Előtte egy cég ajánlatot tett a megoldásra, de akkora összegért, amit nem tudtunk kifizetni. Nem 
tudom, hogy ez arra jó példa-e, hogy külső segítség nélkül is tudunk boldogulni, vagy arra, hogy 
pénzért sok munkát és időt lehetett volna megtakarítani. 


4.2. OpenOffice.org/Libreoffice 


Az OpenOffice.org/Libreoffice-ra való átállás sem zökkenőmentes. A pletykákkal ellentétben nem 
egyes hiányosságok okozzák a zavart, hanem az a rossz gyakorlat, hogy a kollégák úgy szeretnek 
dokumentumot létrehozni, hogy egy korábbi, hasonló tárgyú dokumentumot átírnak. Képzeljünk el 
egy dokumentumot, amit Word 95-ben kezdtek megírni (szépen szóközzel középre húzva a megszó- 
lítást), aztán különböző felkészültségű ügyintézők minden lehetséges Word verzióval belejavítottak 
(van aki ismeri a stílusokat, a többség nem), és a végén ezt OpenOffice.org Writerrel akarjuk meg- 
nyitni, és doc fájlként elmenteni. 

Belátható, hogy az irat tulajdonképpen semmilyen szövegszerkesztőn nem mutat jól, a papíron 
talán nem látszik, de hemzseg a belső hibáktól. Ezt egy SZABVÁNYOS eszközzel megnyitva sok 
hiba a napvilágra jön. 

Persze lehet kidolgozni informatikai megoldásokat a kompatibilitási hibák csökkentésére, de ez 
tipikus példa arra, hogy egy eleve rossz iratkezelési módszert nem lehet jól támogatni számítástech- 
nikai eszközökkel. Nem csak informatikai, hanem iratkezelési, adatbiztonsági szempontból is jobb 
módszer, ha a hivatal előre elkészített sablonokat használ az iratok készítéséhez. Ez nyilván nem in- 
formatikai átszervezést igényel, de az informatika könnyedén tudja támogatni, lényegesen kevesebb 
ráfordítással, mint a rossz gyakorlat fenntartását. 


4.3. Stratégia 


A technikai faltörésünkön kívül büszkék vagyunk a stratégiánkra. Pár éve kialakítottuk és sikeresen 
megvalósítjuk azt az elvet, hogy ha a számtalan különféle szoftverből összeálló rendszert nem is 
tudjuk egységesen lecserélni, új szoftvernek lehetőleg platformfüggetlent, még inkább webes vagy 
JAVA WebStartos kialakításút vegyünk. Szívesen mondanám, hogy alkalmazzunk szabad szoftvert, 
de önkormányzati célalkalmazások (adó, szociális ellátás, ingatlan- nyilvántartás stb.) piacán nem 
jellemzők a szabad szoftverek. Jó példaként mondom: az elmúlt 3 hónapban két olyan ajánlatot is 
kaptunk cégektől, amely szabad szoftverre alapuló megoldást vezetne be. 

Ez a stratégia hosszú távon biztosítja a mozgásterünket a Linux és bármely más várható infor- 
matikai megoldás irányába. A webes megoldások külön előnye a távoli hozzáférés biztosítása, az 
otthoni távmunka megoldásának lehetősége. Ez is egy olyan terület, amely várhatóan nemzetgazda- 
sági megtakarítást hozhat. Talán nem durva kijelenteni, hogy ha egy államigazgatási alkalmazás nem 
webes technológiára épül, az egy kicsit le van maradva, és akkor talán más, szakmai területen sem 
élvonalbeli. 

Mellékesen 2009-ben elkötelezettségünk bizonyítására, no meg hogy tanuljunk az okosabbak- 
tól, szakmai konferenciát rendeztünk „Szabad szoftver az Önkormányzatokban” címmel. Azóta egy 
honlapot is üzemeltetünk ebben a témában: http: / /szabadszoftver.bp18 . hu/. Ez itt a reklám 
helye: olvassátok, és írjatok bele. 
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Itt szeretném név szerint is megemlíteni kollégáimat, Szállási Zoltán csoportvezetőt, Koppányi 
Ferenc, Erdős Attila és Prazsák Péter informatikusokat, hiszen a fal áttörése csapatmunka, amelyben 
mindenkinek szerepe van. 





5. Miért van fal? (Mit tehetnek a magasabb szervek?) 


Ebben a körben nyilván köztudott, hogy az államigazgatás, és az önkormányzati rendszer átalakuló- 
ban van. Még nem igazán tudjuk, hogy az átalakulás mire vezet, végképp nem, hogy milyen informa- 
tikai változást hoz magával. Reméljük, hogy az a világot átfogó mozgalom, amit a szabad szoftverek 
alkalmazása teremt, a magyar közigazgatásba is behatol. Örömmel nyugtázhatjuk, hogy az elmúlt 
időkben konferenciákon újra és újra szóba kerül a szabad szoftverek közigazgatási használatának 
ügye, most is örülünk a kormányzat részéről jött előadóknak. Hallani lehetett az ODF formátum 
államigazgatási bevezetéséről is — szívesen látnánk ezt megvalósulni. 
Mit lehetne még tenni? 


5.1. Ajánlások, szakmai segítség 


Bármilyen sokan is gyűltünk itt össze, sosem képviselünk akkora marketing erőt, mint amit a jog- 
díjakból tudnak a profitorientált vállalkozások megteremteni. Az állampolgárok, az önkormányzati 
vezetők, hivatali döntéshozók, ha nem informatikusok, nyilván jobban el vannak árasztva reklámmal, 
mint a miáltalunk küldött információkkal. Amennyiben a közigazgatás vezetése egyensúlyi helyze- 
tet szeretne teremteni, érdemes lenne ajánlásokat közzétenni, a jó megoldásokat publikálni, példát 
nyújtani. 

A közigazgatást gyakran szidják, hogy pazarló. Itt az alkalom jó példát felmutatni! Egyszer sok- 
sok évvel ezelőtt felmerült, hogy ha a kormányzat egy szabad szoftver megírását támogatja, akkor 
az minden magyar hivatal és önkormányzat számára ingyen elérhető lehet, ahelyett hogy mindenki 
külön-külön megvásárolná. Egységesítést, interoperabilitást is sokkal könnyebben lehet így elérni. 

Természetesen igazi nyílt forráskódú szabad szoftverre gondolok, nem arra, hogy valamely ható- 
ság egy szoftvert kiválaszt, és kötelezővé tesz. Ez olyan versenyhiányt eredményez, ami meglátszik 
azon, hogy a közigazgatásban még floppyról működő DOS-os szoftverek nem kis számban hasz- 
nálatosak. Sajnos ismét meg kell említsem az önkormányzati adózási rendszert, aminek a DOS-on 
túlmutató verziója több mint 11 éve készül, és amit láttunk belőle, félkészen, az már most elavult. 
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6 ÉLET FAL NÉLKÜL (REMÉNYKEDJÜNK...) 





Egy nyílt forráskódú szoftver önmagában hordozza a versenyt. Ha az eredeti fejlesztő nem elég 
naprakész, majd lesz más, aki kiegészíti. A sok-sok magyar hivatal informatikusai is potenciális 
programozók lehetnek: mindenki a maga területének megfelelő tudást tudja hozzátenni egy nyílt 
alkotáshoz. És ez még olcsó is. 

Nagy álomnak tűnik ez, de mi akik itt vagyunk, tudjuk, hogy ez működik, és remek alkalmazá- 
sokat eredményez. 

Magam részéről: minden hivatali, oktatási és otthoni informatikai igényemet ki tudja elégíteni a 
szabad szoftverek halmaza. Ha felmerül egy igény (legutóbb CAD programra volt szükségem), kis 
internetes keresés után már többet is találtam, és már csak válogatni kellett. 

Régen volt egy informatikai tárcaközi bizottság. Egy ilyen, vagy hasonló szerv megtehetné ezt 
a feladatot: különböző közigazgatási feladatokra összegyűjti a megoldásokat, esetleg ajánlásokat 
dolgozna ki, még jobb esetben támogatná az ígéretes kezdeményezéseket. Ezzel segíthetnék a külön- 
böző hivatalok, önkormányzatok döntéshozóit. 


5.2. A jogalkotás lehetőségei 


Még egy meglátásom van, amiért a jogászok meg fognak 
égetni. Nyilván nem egy számítástechnikai megoldást ala- 
pul véve kell jogszabályokat hozni, de nem ártana kodifiká- 
lás közben a megoldhatóságra odafigyelni. A paragrafusok 
alkotása közben gondolni kellene arra, hogy az ügyek folya- 
matokban testesülnek meg, a folyamatokat a szoftverek jól 
tudják modellezni, míg a jogrendszer nem folyamatorien- 
tált. Nem kellene annyi redundáns adat, nem kellene annyi 
független azonosító, nem jó, ha különböző hivatalok más és 
más adatokat tárolnak ugyanarról az objektumról. 

Nyilván a betonút az, ami adott, amihez tervezik az 
autót. De az út tervezésekor is érdemes figyelembe venni, 
hogy milyen gépkocsik vannak forgalomban. 

Ennek a hasonlatnak megfelelően a jogalkotásnál, mun- 
kamódszerek megalkotásánál, űrlapok és nyilvántartások előírásánál jó lenne az informatikai meg- 
valósíthatóságra gondolni. 





6. Élet fal nélkül (Reménykedjünk...) 


Messzire vezetne, ha elmondanám az álmaimat a közigaz- 
gatási informatikáról. Nyilván részben mint informatikus, 
részben mint állampolgár tenném meg. Jó lenne egy egész- 
séges arány a szabad- és a kereskedelmi szoftverek kö- 
zött, jó lenne több webes, sőt mobiltelefonos szolgáltatás, 
jó lenne egy olcsóbb közigazgatás, jó lenne a kismamákat, 
részmunkaidősöket alkalmazó távmunkás ügyintézés. 

Nem kell nagyon aggódni, hogy ez a folyamat lassan 
megy. Stallmann 1983-an alapította a GNU-t, ez a közel 30 
év csak egy röpke pillanat a magyar közigazgatás időszámí- 
tásában, összevetve például azzal, hogy jelenleg több DOS- 
alapú alkalmazás használata kötelező. De ez nem gúnyoló- 
dás akar lenni: az is nagyon nagy baj lenne, ha a közigazga- 
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tási szoftverek, illetve a rendszerek iránti igények olyan gyorsan változnának, mint а szórakoztató 
elektronika. Elég baj az, hogy a jogszabályok túl gyorsan változnak, de ez nem a mi asztalunk. 

Befejezésül egy divatos technológiáról: Jó lesz-e, ha fal helyett felhő lesz? Amennyiben a múlt 
megismétlődik, és a cloud-technológia ismét néhány külföldi nagyvállalat uralmát jelenti nemcsak a 
hardverek és szoftverek, hanem immár az adataink fölött is, akkor nem. 

Amennyiben egységes, átlátható ügyintézést, platformfüggetlen kiszolgálást, minimális költsé- 
geket eredményez az adataink maximális állami- és civil kontrollja mellett, mondjuk egy önálló 
magyar közigazgatási felhőben, akkor igen. De ehhez még meg kell harcolni a mi harcunkat. 

Egy biztos: a fal nem szép. 


75 





76 


Android — két évvel később 


Kis Gergely 
cgergely.kis 2 mattakis.com: 


Tartalomjegyzék 


1. 


2. 


Bevezetés 


Az Android története 


2-1: Akezdétek о zetett fe кл арла н ЖОКТЫ ЖЕКЕ E u e A, 
2.2. Megjelenik az Android 1.0 és a T-Mobile GI ................ 
2.3. 2009: 4 kiadás egy év alatt 1.1, 1.5, 1.6, 2.0 ................. 
2.4. 2010: Az okostelefon piac meghódítása ................... 
2.5. 2011: Tabletek és Jégkrémszendvics  . ..................... 


Az Android 4.0 (Ice Cream Sandwich) újdonságai 


31 Felhasználók: i.a? г» а ар е к КОА ЫК egeszseg СЕП 
3.2. Alkalmazásfejlesztők ............................. 
3.3. РІаіѓогтѓејіеѕёбк. sz вл. жыш дыз. ды Ж жык Л, жй алш Клер 2 


Szemelvények az Android platform belsejéből 


4.1. Az Android Open Source Project — első lépések . .............. 
4.2. Folyamatok, szolgáltatások és ami mindent összeköt: Binder . . . . . . . . 
4.3. Az Android portolása új hardverre ...................... 
4.4. Hová tűnt a forráskód: a kernel.org incidens . ................. 


A sötét oldal 


5.1. Elég nyílt-e az Android? ........................... 
5.2. Elárvult készülékek, a platform fragmentációja . . . . . . . . . . . . . . . 


Kitekintés a jövőbe 


A szerzőről 


77 


78 


78 
78 
79 
79 
79 
79 


80 
80 
80 
81 


81 
81 
84 
86 
87 


87 
87 
89 
89 


90 


2 AZ ANDROID TÖRTÉNETE 





1. Bevezetés 


Az elmúlt bő három évben az Android gyakorlatilag a semmiből nőtte ki magát az okostelefon 
piac egyik meghatározó szereplőjévé. A legutóbbi Szabad Szoftver Konferencián tartott előadásom 
óta sok minden történt az Android világban, megjelentek a tabletek, és immár az Android 4.0 is a 
megjelenés küszöbén áll. 

A továbbiakban áttekintjük a platform történetét valamint jelenlegi helyzetét. Megvizsgáljuk az 
erősségeit, de nem siklunk el a gyengeségei felett sem. Bemerülünk a felszín alá, és felfedezzük az 
Android-világ néhány kevésbé ismert, érdekesebb részletét. Végül kitekintünk a jövőbe, a spekulá- 
ciók és összeesküvés-elméletek világába. 


2. Az Android története 


2.1. A kezdetek 


Kevésbé ismert talán, hogy az Android története nem a Google-nál kezdődött. A , hivatalos" törté- 
netírásban általában a következőket találjuk: 


e 2003-ban alapította az Android Inc.-et 4 ember, Rich Miner, Andy Rubin, Chris White és Nick 
Sears. 


e 2005-ben vásárolta fel a céget a Google. 


2006-ban jelentek meg az első pletykák, hogy a Google tervezi a belépést a mobilpiacra. 


e 2007 végén megalakul az Open Handset Alliance. Az alapító tagok között van: Google, HTC, 
Motorola, Intel, Oualcomm, Sprint Nextel, T-Mobile és az NVIDIA 


Szintén 2007 végén kiadják az Android SDK első béta verzióját, és bejelentik a 10 millió 
dollár összdíjazású Android Developer Challenge-et. 


2008 szeptemberében kiadják az Android 1.0-át és az első telefont a G1-et. 


Valójában az Android technológiai gyökerei egészen a BeOS-ig nyúlnak vissza. A Binder rend- 
szert itt kezdte el fejleszteni Dianne Hackborn és kollégái, ami a következő generációs BeOS alapja 
lett volna. A fejlesztést a PalmSource-nál fejezték be (miután a Palm felvásárolta a Be Inc.-t), és 
a „PalmOS Cobalt’ kódnevű rendszernek alapja volt. Ez az OS végül nem került széles felhaszná- 
lásra, és a Palm nyílt forrásúvá tette a Binder egy verzióját OpenBinder néven. 2006-ot írtunk ekkor, 
amikor Dianne Hackborn a Google-nél folytatta a munkát, és ma már tudjuk, hogy a Binder az And- 
roid alapvető keretrendszere lett. Kicsit később visszatérünk még a Binderre, hogy részletesebben is 
megismerjük. 

Nagyon izgalmas időszak volt 2007 vége és 2008 eleje. Mindenki próbálgatta az akkor még igen 
kezdetleges SDK-t, és aki tehette, megpróbálkozott az Android Challenge-en történő részvétellel is. 

Szinte naponta jelentek meg új hardverportok, amikor pár lelkes fejlesztő az SDK-t addig re- 
szelte, amíg egy kompatibilis CPU-val rendelkező eszközön sikerült elindítani, és néhány funkcióját 
kipróbálni. Jómagam egy Sharp Zaurusra portoltam ilyen módon ezt az első nyilvános Android ver- 
ziót. 
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2.2 Megjelenik az Android 1.0 és a T-Mobile G1 








Ezt egyébként a közösség tagjai a mai napig csinálják, most az Android 4.0 (Ice Cream Sand- 
wich) SDK portolása a sláger a legkülönfélébb eszközökre. A Google ígérete szerint a Galaxy 
Nexus megjelenése után nem sokkal elérhető lesz az új platformverzió teljes forráskódja, és 
megindulhat a valódi portolási munka például a CyanogenMod projekt keretén belül. 











2.2. Megjelenik az Android 1.0 és a T-Mobile G1 


2008 szeptemberében kiadják az Android 1.0-át és a T-Mobile G1-et. Ezzel elindul az Android plat- 
form, hogy meghódítsa a világot. Természetesen elkerülhetetlen, hogy az iPhone megjelenéséhez 
hasonlítsuk ezt az időszakot. Az iPhone-hoz képest a végfelhasználók részéről sokkal kisebb volt az 
érdeklődés, ennek egyik oka volt az is, hogy kizárólag a T-Mobile USA hálózatán volt elérhető az 
első időszakban a készülék, melynek kevésbé jó a lefedettsége, mint az iPhone-t akkoriban kizáróla- 
gosan forgalmazó AT&T-nek. 

Fejlesztőként viszont mindenképpen új fejezet kezdődött: ez volt az első eset, hogy egy teljes, 
készülékekre telepíthető, általános felhasználásra alkalmas mobiltelefon platform nyílt forráskódú 
lett. Jómagam óvatos szkepticizmussal vártam a kódnyitást, azt feltételeztem, hogy a korábbi ha- 
sonló esetekhez hasonlóan csak részeket nyit meg a Google, és több hónapos munkába kerül majd 
egyáltalán emulátorban működésre bírni. Ehhez képest nagyon kellemes meglepetés volt, hogy egy 
jól dokumentált, 3 paranccsal lefordítható, az emulátorban azonnal működő (1-2 hónappal később 
már G1-esen is futtatható) rendszert kaptunk. 


2.3. 2009: 4 kiadás egy év alatt 1.1, 1.5, 1.6, 2.0 


2009-ben egy év alatt 4 új Android verzió jelent meg. A platform elérte a 2.0-ás mérföldkövet, 
közben már tucatnyi különböző típusú eszközön található az Android hivatalosan (és még többön 
nem hivatalosan). 


2.4. 2010: Az okostelefon piac meghódítása 


2010-re a korábban szkeptikus hangoknak is el kellett ismerniük, hogy az Android vezető tényezővé 
vált, és az okostelefonok piacának jelentős szegmensét tekintheti magáénak. Ebben segíti az, hogy 
a platform gyártófüggetlen, így a felhasználók sok különböző gyártó rengeteg féle készülékéből 
válogathatnak. 


2.5. 2011: Tabletek és Jégkrémszendvics 


Idén jelentek meg az első Android-alapú tabletek, amelyek már az Android 3.x-et (Honeycomb) 
futtatják. A nagyobb képernyőterülethez új felületet terveztek a Google mérnökei. Azonban, hogy 
tartani tudják a lépést az iPaddel, gyorsabban ki kellett adniuk az új verziót, minthogy olyan rendszert 
készíthettek volna, ahol a telefonokhoz szánt felület és a tabletekhez szánt felület egymás mellett 
működhetett volna. Ezért úgy döntöttek, hogy csak az Ice Cream Sandwich forráskódját adják ki, 
mely már összeolvasztja a két fejlesztői ágat (2.x és 3.x), és a képernyőmérettől függően az annak 
megfelelő felülettel lehet használni. Ez minden jel szerint néhány héten belül várható, amint a Galaxy 
Nexus a boltokba kerül. 

Közben az Android részesedése tovább nő az okostelefon piacon is. A Nielsen 2011 3. negyed- 
évre vonatkozó adatai alapján az USA okostelefon piac 43%-át Android eszközök uralják, míg az 
1О$ eszközök 28%-оп, a BlackBerry 18%-оп, a Windows Phone 7%-оп állt. 
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3 AZ ANDROID 4.0 (ICE CREAM SANDWICH) ÚJDONSÁGAI 





3. 


Az Android 4.0 (Ice Cream Sandwich) újdonságai 


A több szempontból is nagyon várt Ice Cream Sandwich platform sok újdonságot hoz. Tekintsük át 
röviden, a teljesség igénye nélkül, hogy mit várhatnak a felhasználók és a fejlesztők. 


3.1. 


3.2. 


Felhasználók 


A nemrég használt alkalmazások vizuális megjelenítése 
A Home Screen-re helyezhető mappák és kedvenc alkalmazások dokkoló 


Átméretezhető, interaktívabb app widgetek — akár e-mailt is olvashatunk külön alkalmazás 
indítása nélkül 


Több funkció érhető el a telefon lezárt állapotában is: jelzések, kamera, zenelejátszó 
Gyors SMS válasz bejövő hívásokra közvetlenül a zárolási képernyőről 
Továbbfejlesztett szövegbevitel és helyesírás-ellenőrzés 

Hanggal vezérelt szövegbevitel, folyamatos diktálás 

A hálózati forgalom finomhangolása forgalomdíjas előfizetéssel rendelkezők részére 
Továbbfejlesztett kamera, galéria alkalmazás szerkesztőfunkciókkal 

Valósidejű videoeffektek 

Egységesített naptár 

Android Beam — МЕС alapú adatmegosztás 

Wi-Fi Direct — közvetlen Wi-Fi kapcsolat közelben levő eszközökkel 

Bluetooth Health Device Profile — Az Android kapcsolódhat egészségügyi berendezésekhez, 


szenzorokhoz adatgyűjtés céljából 


Alkalmazásfejlesztők 


Az Android 3.x korábban csak tableteken elérhető funkciói elérhetők mobiltelefonokon is, 
többek között: 

— Hardveresen gyorsított 2D grafika 

— Többszörös kijelölés, drag & drop, vágólap 


— Renderscript 3D grafika amely potenciálisan lehetővé teszi komplex megjelenítési fel- 
adatok a GPU-n történő végrehajtását 


- HTTP Live streaming, Bluetooth AZDP és HSP profilok, RTP protokoll támogatása 
- DRM keretrendszer 
— Továbbfejlesztett bevitel: billentyűzet, egér, gamepad, joystick támogatás 


— Üzleti funkciók: Teljes titkosítás és házirendek a titkosított tárolás és jelszavak kezelé- 
sére 
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3.3 Platformfejlesztők 





e Szolgáltatófüggetlen Social API, amellyel egyszerre több hálót kezelhetünk egységes módon 


e Media streaming API — Eddig nem volt arra lehetőség, hogy egy alkalmazás saját maga ke- 
zelje a lejátszani kívánt média adatátvitelét, pl. egy saját protokoll használatával. Mostantól 
lehetővé válik, hogy МРЕС2Т$ formátumban közvetlenül streamet küldjünk a lejátszórend- 
szernek. 


e Text Service API — Lehetővé vált külső helyesírás-ellenőrzők integrálása a platformba, így 
akár a Hunspellt is használhatjuk majd. 


3.3.  Platformfejlesztők 


A legnagyobb újdonság értelemszerűen az, hogy végre ismét hozzáférhetünk majd a teljes And- 
roid platform forráskódjához. Emellett a Google fejlesztők már azt is megosztották velünk, hogy 
az elmúlt 1 év alatt jelentősen meghízott a platform, így a fejlesztői gépekkel szemben támasztott 
elvárások is megnövekedtek: 


e 6GB letöltés 

e 25 ОВ tárhely egy buildhez 

e 80 ОВ tárhely az összes AOSP konfiguráció fordításához 

e 16 GB RAM ajánlott, ha kevesebb van, akkor javasolt SSD használata 
e 5+ óra CPU-idő egyetlen buildhez 


A fenti összefoglaló korántsem teljes, ennél sokkal több mindent találhatunk az Android fejlesz- 
tői oldalán (http://developer.android.com). 


4. Szemelvények az Android platform belsejéből 


4.1. Az Android Open Source Project — első lépések 


Az AOSP projektet a Google hozta létre, amelynek fő feladata a platform nyílt forrású kiadásai- 
nak kezelése, és lehetőség biztosítása arra, hogy külső fejlesztők hozzájárulhassanak a platformhoz. 
A projekt weboldalán (http://source.android.com) elérhető részletes dokumentáció, amellyel bárki 
nekivághat a platformfejlesztésnek. 

A forráskód letöltése és lefordítása néhány parancs segítségével könnyen megtehető egy modern 
Linux (Ubuntu LIS a támogatott) vagy Mac OSX 10.6 rendszeren. 

Az AOSP а git verziókezelőt használja, de a projekt méretéből fakadóan nem egy darab repo- 
sitoryt használ, hanem komponensenként / alrendszerenként egyet, összesen kb. 160-170-et a Gin- 
gerbread (2.3.x) kiadásban. Ezeknek az együttes kezelését a repo segédprogram végzi a következő 
módon. 


1. Letöltjük a repo shell szkriptet és elhelyezzük egy, a PATH változóban található könyvtárba: 





curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > -/bin/repo 


2. Létrehozzuk a könyvtárat, ahova le kívánjuk tölteni a forráskódot: 
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mkdir droid ; cd droid 


3. Inicializáljuk a repo eszközt: 


repo init -u https://android.googlesource.com/platform/manifest 


Az itt megadott URL-en egy git repository található, ami a repo manifest fájlokat tartalmazza. 
Alapértelmezésben a master branchen található default.xml elnevezésű fájlt használja, ez ter- 
mészetesen parancssori paraméterekkel felülírható. Ebben a fájlban vannak felsorolva a git 
repositoryk, valamint az elérési út ahová a forráskódba be kell illeszteni az egyes repository- 
kat. 


4. A következő parancs hatására megkezdődik a forráskód letöltése (illetve meglevő letöltés ese- 
tén frissítése): 


repo sync 


Ez a művelet az internetkapcsolat sebességétől függően hosszú ideig is eltarthat, mivel több 
GB adat letöltésére van szükség. 


A folyamat végén a gépünkön elérhető lesz az Android teljes forráskódja a nyilvános kódtörté- 
nettel együtt. Ezután már csak le kell fordítanunk a rendszert. Az AOSP weboldalán megtalálható 
azon csomagok listája, melyeket telepítenünk kell, hogy megkezdhessük a fordítást. 

A telepítés után csupán 3 parancsot kell kiadnunk: 


build/envsetup.sh 
lunch 
make -j 4 2>&1 | tee b-1.log 


A lunch parancs segítségével konfigurálhatjuk, hogy milyen eszköz számára szeretnénk lefordí- 
tani a rendszert. A mindenki számára működő lehetőség természetesen az emulátor, de a Ginger- 
bread kiadásban lehetőségünk van a Nexus One (passion) és a Nexus S (crespo) kiválasztására is. 
Ha nem emulátor számára fordítunk, akkor szükségünk lesz még a fordítás megkezdése előtt néhány 
olyan fájlra, melyek csak a készülékről, vagy egy hivatalos frissítőcsomagból érhetők el. Ezek ál- 
talában firmware fájlok, illetve zárt forrású driverek (pl. OpenGL, GPS vagy a GSM modem). A 
fájlok kigyűjtéséhez a projektben elérhető szkripteket használhatjuk, részletek az AOSP honlapján 
olvashatók. 

A fordítás eredményét az out/target/product/productname/ könyvtárban találjuk. 

Innen (amennyiben emulátorra fordítottuk a rendszert) már csak az emulator parancsot kell ki- 
adnunk, és ki is próbálhatjuk a frissen fordított Android rendszerünket. Ha hardveren szeretnénk 
futtatni, akkor a feltöltés leggyorsabb módja a fastboot parancs használata: 


fastboot flash boot boot.img 
fastboot flash system system.img 
fastboot flash recovery recovery.img 
fastboot erase cache 

fastboot erase userdata 





Amennyiben már van az eszközünkre egy kényelmes recovery rendszer telepítve (pl. a Clock- 
workMod recovery), nem szükséges azt felülírnunk. 
Ejtsünk néhány szót az elkészült image-ekről / partíciókról: 
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e boot: Ez az image tartalmazza a kernelt és az initrd-be csomagolt root fájlrendszert 


e system: Ez az image tartalmazza a /system tartalmát, gyakorlatilag az összes rendszerprogra- 
mot és előretelepített alkalmazást. 


userdata: Ezen a partíción találhatók a felhasználói adatok, melyek a futó rendszeren a /data 
alatt találhatók. Ide kerülnek az utólag telepített alkalmazások is, valamint minden alkalma- 
zásnak itt található a saját privát könyvtára is. 


e cache: Átmeneti adatok tárolására szolgáló partíció, például ide tölti le a rendszer a szoftver- 
frissítéseket vagy a weboldalakról letöltött fájlokat. 





A userdata és a cache partíciók tartalma nem minden esetben kompatibilis a különböző Android 
rendszerverziókkal. (A hivatalos frissítéseknél persze figyelnek arra, hogy ilyen gond lehetőleg 
ne legyen.) Ha ilyet tapasztalunk, pl. alkalmazások nem indulnak, akkor ezen partíciók tartal- 
mának a törlése jelenthet megoldást. Ezt szokták , data wipe”-nak is hívni. 











Amennyiben készen állunk arra, hogy megtegyük első módosításunkat, létre kell hoznunk egy 
feature branchet, ahova dolgozni fogunk: 


repo start branchneve [геро1 геро2 ....] 


Alapértelmezésben ez minden git repositoryban létrehozza a branchet, de korlátozhatjuk csak 
megadott alrendszerekre. 

A módosításainkat a szokott módon tehetjük meg és commitolhatjuk a git segítségével. Amikor 
elkészültünk a módosításunkkal, a repo upload parancs segítségével tölthetjük fel az Android code 
review rendszerébe. 

Az Android projekt a Gerrit nevű rendszert használja, amit eredetileg a repo-val együtt az Andro- 
idhoz fejlesztettek ki, de ma már egyéb projektek is használják. Integrálja a git repositoryk kezelését, 
a beküldött módosítások ellenőrzését és közvetlen commitolását. Emellett sokféle rendszerrel képes 
integrálódni, például a felhasználók kezelésére: OpenID, LDAP ... stb. Szintén nyílt forráskódú 
projekt (a repo-val együtt). Az Android eszközöket készítő cégek jelentős része ezt használja a saját 
belső fejlesztéseik koordinálására. 

Az AOSP-ben a kommunikáció levelezőlistákon (Google csoportok) zajlik, itt kérhetünk segítsé- 
get, ha elakadnánk valahol: 


e android-platform: Általános fejlesztői kérdések a platformmal kapcsolatban 


e android-contrib: Konkrét beküldendő vagy beküldött módosításokkal kapcsolatos lista 


android-building: A platform fordítása során keletkező problémák megbeszélése 


android-kernel: Az Android Linux kernellel kapcsolatos beszélgetés 
e android-porting: Az Android új eszközökre portolásával kapcsolatos kérdések 


e repo-discuss: A repo és Gerrit eszközök fejlesztése 


Minden listát olvasnak a Google fejlesztők és aktívan részt vesznek a beszélgetésben / támoga- 
tásban is. 
Magyar nyelvű segítséget az android-hu Google csoportban kaphatunk. 


83 


4 SZEMELVÉNYEK AZ ANDROID PLATFORM BELSEJÉBŐL 





4.2. 


Folyamatok, szolgáltatások és ami mindent összeköt: Binder 


A Binder felelős azért, hogy a különböző Android folyamatok / szolgáltatások kommunikálni tudja- 
nak egymással. Hasonló technológiák nem ismeretlenek a hagyományos Linux rendszerekben sem. 
A modern Linux desktopok hasonló célokra a D-BUS-t használják, de sokkal kisebb mértékben, 
mint az Android a Bindert. A Binder főbb tulajdonságai: 


Objektum-orientált megvalósítás: A Binderben interfészeket megvalósító objektumok kom- 
munikálnak egymással távoli metódushívások segítségével, nem csak strukturálatlan üzenet- 
küldés történik. 


Objektum azonosítás: Lehetőség van arra, hogy egy Binder objektumreferenciát továbbküld- 
jünk egy másik objektumnak. Ezt akárhányszor tesszük is meg, a referencia mindig az eredeti 
Binder objektumra fog mutatni. Így lehetőségünk van az objektumreferenciákat azonosság- 
ellenőrzésre is használni. 


Biztonság: A Binder hívások feldolgozásakor ellenőrizhetjük, hogy a hívó félnek milyen jo- 
gosultságai és a folyamatának milyen uid-je van. Ez a két eszköz képzi az Android biztonsági 
keretrendszerének alapját. 


Teljesítmény: A Binder elég gyors ahhoz hogy az egész Android rendszert rá építsék. Ráadásul 
lehetőség van file descriptorok átadására is, melynek segítségével memóriaterületek, nyitott 
fájlok vagy socketek oszthatók meg könnyen és biztonságosan a folyamatok között. Így van 
arra lehetőség, hogy a SurfaceFlinger (a grafikus hardvert kezelő komponens) lefoglaljon egy 
memóriaterületet egy ablak számára, amit átad a Window Manager-nek. A Window Manager 
ezt a területet továbbadhatja az ablakot igénylő alkalmazásnak, így az alkalmazás közvetlenül 
a videomemóriába tud rajzolni anélkül, hogy közvetlen jogosultságot kéne adni számára a 
videomemória eléréséhez. 


Minden objektumorientált IPC (inter-process communication) megoldásnál 3 fogalommal kell 
megismerkednünk: 


Interface: Az interfész meghatározza azokat a műveleteket, amelyeket a távolról meghívható 
objektumunkon végezni tudunk. 


Proxy: A hívó oldalon található, megvalósítja az interfészt, és a metódushívásokat az IPC 
rendszeren keresztül átküldi a távoli objektumhoz. 


Stub: Fogadja az IPC rendszertől érkező kéréseket, átalakítja a helyi metódushívásokká, vala- 
mint az IPC rendszeren keresztül visszaküldi a hívó fél számára az eredményt. 


A Bindert lehet használni az Android SDK használatával Javaból, vagy közvetlenül a platform kód- 
ból С++-Ыб1. Az SDK része az aidl segédeszköz, amely egy AIDL nyelvű (Javara nagyon hasonlító) 
interfész leírásból legenerálja a stub és proxy osztályokat Java nyelven. Sajnos C++-hoz kézzel КеП 
megírnunk ezeket az osztályokat, de mint látni fogjuk, ez sem nehéz. 

A következőkben bemutatok egy egyszerű összeadó szolgáltatást, ahol a paraméterekben átadott 
számok összegét kapjuk vissza eredményben. 

Az interfészünk így néz ki: 


class IAddService: public IInterface 


( 


public: 








DECLARE META INTERFACE (AddService); 




















virtual int32 t add(int32 t a, int32 t b) — 0; 
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4.2 Folyamatok, szolgáltatások és ami mindent összeköt: Binder 





}; 


enum { 
ADD = IBinder::FIRST CALL ТВАМЅАСТІОМ 
}; 





А Proxy osztályunk: 





class BpAddService: public BpInterface<IAddService> 

( 

public: 
BpAddService(const sp<IBinder>& impl) : BpInterface<IAddService> (impl) 
{ 
} 





int32 t ааа (int32 © а, іпі32 + БЫ) 
{ 
Parcel data, reply; 
data.writeInterfaceToken (IAddService: : getInterfaceDescriptor () ) ; 
data.writeInt32 (a); 
data.writeInt32 (b); 
remote ()->transact (ADD, data, &reply); 
return reply.readInt32(); 











}; 


A Stub osztályunk: 


class BnAddService: public BnInterface<IAddService> 
{ 
public: 
virtual status_t onTransact( uint32_t code, 
const Parcel& data, 
Parcel» reply, 
uint32_t flags = 0) { 





switch (code) 


{ 


case ADD: 


{ 











CHECK_INTERFACE (IAddService, data, reply); 
int32 t a = data.readInt32(); 

int32 t b = data.readInt32(); 

int32_t result = add(a, b); 
reply->writeInt32 (result); 

return NO ERROR; 

break; 











} 
default: 
return BBinder::onTransact (code, data, reply, flags); 


; 


Végül természetesen implementálnunk kell az interfészt megvalósító osztályt is: 
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class AddService: public BnAddService 
{ 
public: 
virtual iíint32.t add(int32 t a, int32 t b) ( 
return a + b; 
} 
}; 


Mint látható а fentiekből, egy távoli metódushívás tranzakció összeállításához csupán az adott in- 
terfész azonosítóját, a metódus belső (csak a proxy és stub implementáción belül értelmezett) kódját, 
és a metódushívás paramétereit kell összeállítanunk, illetve a szerver oldalon feldolgoznunk. 

Lássunk egy konkrét példát a Binder használatára. Egy modern operációs rendszernek fontos, 
hogy jó multimédiás képességei legyenek, ideértve a hang- és videofelvétel és -lejátszás kezelését. 
Android rendszereken ezt a mediaserver folyamat végzi. A mediaserveren belül több szolgáltatást is 
találunk: 


e AudioFlinger: a különböző hangforrások mixelését és a hardverhez juttatását végzi, illetve 
kezeli a hangfelvételt is. 


e Stagefright: általános médialejátszó és felvevő keretrendszer 


Adódik a kérdés, hogy a Java nyelven írt alkalmazásokban használható MediaRecorder és Me- 
diaPlayer osztályok hogyan kapcsolódnak a mediaserverhez. A megoldást ismét a Binder framework 
jelenti. Mind a MediaPlayer mind a MediaRecorder Java osztály egy-egy Binder interfészhez kap- 
csolódik, melyeket a mediaserver szolgáltat. Kihasználva a Binder azon tulajdonságát, hogy file 
descriptorokat adhatunk át közvetlenül más folyamatoknak, lehetővé válik, hogy a mediaserver a 
Java alkalmazás által megnyitott fájlokat játsszon le. 


4.3. Az Android portolása új hardverre 


Azt a technológia iránt érdeklődő emberek többsége tudja, hogy az Android a Linux kernelre épül. 
Tehát minden rendszeren, ahol van működő Linux változat, fut az Android is — gondolhatnánk. A 
helyzet azonban nem ennyire egyszerű, mivel az Android a hagyományos Linux (GNU / Linux) rend- 
szerektől különböző userlandet (a kernel által futtatott felhasználói programok összessége) használ. 

Ide tartozik a fentebb részletesen bemutatott Binder, de a libc is egy BSD gyökerekkel rendel- 
kező, a GNU/Linux rendszereken általában használt glibc-vel binárisan nem kompatibilis könyvtár. 
Ez azt is jelenti, hogy minden programot, melyet egy Android rendszeren szeretnénk futtatni, újra 
kell fordítani. 

Lássuk hát részletesen, mi szükséges ahhoz, hogy egy új hardveren használatba vehessük az 
Androidot: 


e Kell egy Android patcheket tartalmazó, megfelelő verziójú Linux kernel. Ezek a patchek tar- 
talmazzák többek között a binder kernelbeli részét, az ashmem osztott memória drivert, és 
a különféle, energiagazdálkodással kapcsolatos módosításokat. Beágyazott rendszereknél a 
, megfelelő" kernelverzió beszerzése sem mindig egyszerű, mivel nem minden gyártó küldi be 
a hardvereik támogatását a hivatalos , vanilla" kernelfába. Így sokszor arra vagyunk utalva, 
hogy a chipset-gyártó mikor készít el egy Androidhoz is megfelelő verziójú kernelt. 


e A legfontosabb (assembly kódokat is tartalmazó) komponensek portolása a hardver processzo- 
rához. A teljesség igénye nélkül:: libc, Dalvik (az Android alkalmazások virtuális gépe), Skia 
(2D rajzolási feladatok). Szerencsére a 3 legelterjedtebb processzorcsaládhoz (ARM, MIPS, 
x86) már van működő változat, így ezekkel a legtöbb esetben nem kell foglalkoznunk. 
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A portolás talán leglátványosabb része, amikor a megjelenítést végző komponenst (SurfaceF- 
linger) portoljuk. Sajnos ez okozza legtöbb problémát is, mivel sok esetben a grafikus chip 
dokumentációja nem hozzáférhető, és a driverkönyvtárak csak bináris formában érhetők el. 
Ilyen esetben a chip beszállítóján múlik, hogy kiad-e Android drivert, illetve milyen gyorsan 
frissíti a drivert egy új Android verzió megjelenése után. 


Hasonlóan problémát jelent a videolejátszásnál használt codecek portolása. Itt is csak a leg- 
ritkább esetben érhető el a gyorsítóchipek dokumentációja, tehát ismét a hardvergyártóra va- 
gyunk utalva. 


Ezután következik az egyéb hardver driverek portolása: hang, GPS . . . stb. Itt a legtöbb esetben 
nem a kernel driverekre kell gondolni, hanem a felhasználói programként futó részekre, pl. 
ALSA driver illesztés az Android frameworkhöz, vagy egy GPS daemon. 


4.4. Hová tűnt a forráskód: a kernel.org incidens 


Mint az ismeretes augusztus közepén kiderült, hogy feltörték a kernel.org infrastruktúra egyik köz- 
ponti szerverét. Emiatt a korábban innen kiszolgált Android forráskód is elérhetetlenné vált. A 
Google alkalmazottak , nincs még semmi bejelenteni valónk" válaszai nem segítettek eloszlatni az 
aggodalmakat, hogy mikor válik a forráskód újra elérhetővé. 

Végül az Android 4.0 bejelentésekor megkaptuk a választ: az AOSP forráskódokat mostantól a 
Google a saját szerverein keresztül teszi elérhetővé, nem veszik igénybe a kernel.org segítségét. АШ- 
tásuk szerint már a biztonsági incidens előtt dolgoztak az átálláson, hiszen a kernel.org infrastruktúra 
nehezen birkózott már meg az új Android verziók megjelenésekor jelentkező igényekkel, amelyek a 
kernel.org többi szolgáltatására 15 negatív hatást gyakoroltak. 

A feltörés után ezért úgy döntöttek, hogy meg sem próbálják a régi rendszeren újraindítani a 
szolgáltatást, hanem megvárják, amíg elkészül a saját kiszolgálórendszer. 


5. А sötét oldal 


Ebben a fejezetben áttekintjük az Android árnyoldalait, problémáit, melyeknek megoldása még várat 
magára. 


5.1. Elég nyílt-e az Android? 


Ez a téma talán az egyik legkedveltebb mostanság (közvetlenül a biciklitároló (bikeshed) színének 
megvitatása után). Amikor valaki azt mondja, hogy az Android nem eléggé nyílt, általában 2 dolgot 
ért alatta. 


e Nincs hivatalos útiterv-/ ütemterv, tehát nem lehet előre tudni, hogy mikor érkezik új verzió, 
és abban milyen új funkciók mutatkoznak be. 


e Ahhoz, hogy valódi hardverekre tudjuk telepíteni az Androidot, szükség van zárt forrású kom- 
ponensekre. 


Vegyük át kicsit részletesebben, hogy ez mit jelent. 
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Útiterv nélkül 


A Google-nek általában az az üzletpolitikája, hogy nem nyilatkozik ütemtervekről és funkciótervek- 
ről. Természetesen ez sincs kőbe vésve, például a Google App Engine-nél a többi Google termékhez 
képest sokkal részletesebb ütemtervet találunk. Ez a stratégia a Google szempontjából érthető: 


e Csúszás, vagy tervezett funkciók kiesése esetén nem kell kellemetlen sajtótájékoztatókat tar- 
tani. 


e Jól irányzott kiszivárogtatásokkal / pletykákkal hatékonyan fent lehet tartani az érdeklődést 
hivatalos nyilatkozatok nélkül is. 


Ettől természetesen még nem lesz kevésbé frusztráló ez az üzletpolitika mindenki más számára. 

Az Android esetében azt láttuk, hogy negyedéves pontossággal mindig behatárolták a következő 
kiadás megjelenésének időpontját, valamint körülbelül 1 hónappal az új verziót futtató első készü- 
lékek megjelenése előtt már elérhető volt az új SDK verzió, így a fejlesztőknek elég idejük lehetett 
arra, hogy az alkalmazásaikat frissítsék. 

Az AOSP forráskód kiadásánál már nem ment minden ennyire zökkenőmentesen. Az 1.x-es 
változatoknál még viszonylag gyorsan elérhető volt a készülék megjelenése után, de a 2.x időszakban 
előfordult több hónapos várakozás is, és a 3.x-es platformváltozatok forráskódja valószínűleg soha 
nem lesz elérhető a nyilvánosság számára. 

Itt érdemes egy kis kitérőt tennünk a különböző nyílt forrású fejlesztési modellek felé. Amikor 
nyílt forrású projektről beszélünk, akkor nagyon gyakran arra gondolunk, hogy nem csak a projekt 
eredménye (a stabil kiadások) nyílt forráskódúak, hanem a teljes fejlesztési folyamat is nyíltan folyik. 
Talán a két legismertebb ilyen jellegű projekt a Linux kernel fejlesztése és a Debian Linux fejlesztése. 

Ezzel szemben egy másik modellt képvisel a kereskedelmi nyílt forrású projekt, ahol egy profit- 
orientált cég adja ki a fejlesztés eredményeit nyílt forrású termékként. Ilyenekre sok példát találunk 
pl. az üzleti szoftverek piacán az OpenERP és az OpenBravo, vagy az ExtJS javascript keretrendszer. 
Ebbe a csoportba sorolható a RedHat Enterprise Linux disztribúciója is. 

A kereskedelmi nyílt forrás (commercial open-source) modellben gyakori, hogy csupán a végle- 
ges verziók érhetők el nyílt forrású termékként, míg a fejlesztői változatokat csak egy szűkebb kör 
(általában a kiemelt ügyfelek) ismerhetik meg. A fejlesztés túlnyomó részét ilyen projektek esetében 
a forráskód felett jogilag ellenőrzést gyakorló szervezet fejlesztői végzik, és a külső hozzájárulók 
inkább kisebb javításokat, illetve kiterjesztéseket készítenek. A fejlesztés irányvonalát is a jogtulaj- 
donos határozza meg, üzleti érdekei mentén. 

Az Android projekt egyértelműen az utóbbi csoportba tartozik. Ha így tekintjük át a projekt folya- 
matait, akkor egy átlagos „commercial open-source” projektet látunk, az átlagnál jobb eszközökkel, 
melyek segítik a külső hozzájárulók munkáját. 

Természetesen, mint Android fejlesztő és felhasználó is örülnék annak, ha több információ lenne 
publikus a készülő új funkciókról. Azonban reálisan gondolkodva egy ilyen lépés sértené mind a 
Google, mind készülékgyártó partnerei érdekeit. A mobilpiacon nagyon éles a verseny, és néhány 
hónap leforgása alatt teljesen átrendeződhet a helyzet. Erre maga az Android a legjobb példa, hiszen 
2 év alatt vált a semmiből piacvezetővé. Ugyanez fordítva is lejátszódhat bármikor. 


Zárt forrású komponensek 


Kétségtelen tény, hogy a modern hardvereszközök dokumentációjához csak a legritkább esetben 
férhetünk hozzá titoktartási nyilatkozat nélkül, amely az esetek túlnyomó többségében kizárja a nyílt 
forrású driver megvalósítást. Ez a beágyazott rendszerekre hatványozottan igaz. Sok esetben még a 
partnerek is csupán az egyes driverek, pl. az OpenGL driver bináris verzióját kaphatják meg. 

A jogszabályi környezet és a piaci folyamatok miatt valószínűtlen ennek a helyzetnek a megvál- 
tozása belátható idén belül. 
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5.2. Elárvult készülékek, a platform fragmentációja 


Bejárta az Internetet az understatement.com cikke, amely jól bemutatja, hogy milyen problémák van- 
nak az Android készülékek operációs rendszer támogatásával. Sajnos, ellentétben az iPhone-nal, az 
Android esetében nem biztosított az, hogy egy megvásárolt készülék az átlagosan 2 éves hűségnyi- 
latkozat lejártáig mindig a legfrissebb szoftvert futtassa. 

Tény, hogy itt az Apple stratégiája rengeteg előnyt jelent. Az iPhone-nál mindent az Apple irá- 
пуй (beleértve a hardvert és a szoftvert 15), így könnyebben tudja a régebbi eszközöket is támogatni. 
A másik jelentős különbség, hogy az iPhone esetében a készülékgyártó elemi érdeke, hogy a készülé- 
keket használni tudják tulajdonosaik, hiszen ekkor fognak az alkalmazásboltban bevételt generálni. 

Az Android esetében (tudomásom szerint) a készülékgyártók nem kapnak közvetlen részesedést 
az alkalmazások értékesítéséből befolyt bevételből, így nem érdekeltek a már eladott készülékek 
további támogatásában. Amíg ez a helyzet nem változik, sajnos nem számíthatunk számottevő javu- 
lásra. 

Természetesen a Google is látja a problémákat, és megpróbálnak különböző eszközökkel hatni 
a készülékgyártókra, például, akik jobb támogatást vállalnak, azok hamarabb férhetnek hozzá a fej- 
lesztés alatt álló és még nem publikus Android forráskódokhoz. 

Érdemes azt is figyelembe venni, hogy az Android piac összetétele teljesen más, mint az iPhone 
esetében. Minden egyes iPhone változat kiadásának pillanatában hardver szempontból felső kate- 
góriás készüléknek számított, amelyek még több év elteltével is elfogadható teljesítményt tudnak 
nyújtani. 

Ezzel szemben az eladott Android készülékek jelentős része , belépő szintű", kisebb erejű, kifutó 
hardverelemekre épül, ez teszi lehetővé, hogy valóban fillérekért megvásárolhatók legyenek. Ez azt 
is jelenti, hogy egy ilyen, technológiai szempontból már megjelenése pillanatában elavult eszköznél 
a több évig folyamatos rendszerfrissítés biztosítása csak jelentős többletköltséggel és fájó kompro- 
misszumok árán lenne megoldható. 

Ennek a helyzetnek a megoldása közel sem triviális. Például a Google megtehetné, hogy jobban 
megköti a gyártók kezét, akik a Google alkalmazásokat (beleértve az Android Marketet) is terjeszteni 
szeretnék, és megkövetelik azt, hogy csak közép- és felsőkategóriás hardverrel rendelkező eszközö- 
ket dobnak piacra. Ez azonban csak tovább rontaná a helyzetet: 


e Az Android jelentős piacvesztést szenvedne el a belépő szintű okostelefonok piacán, akár (a 
már folyamatosan temetett) Symbian, akár egyéb proprietary platformok, mint pl. a Samsung 
Bada előnyére. 


e Az Android nyílt forráskódú volta miatt gyártók továbbra is készíthetnének belépő szintű esz- 
közöket, ezek azonban a Google alkalmazások nélkül kerülnének a felhasználókhoz, amely 
korántsem nyújtaná a megszokott élményt, és sok bosszúságot szülne a vásárlók számára. Ez 
megint csak negatívan befolyásolná a platform megítélését 


Egy másik lehetséges megoldás lehetne a belépő szintű, valamint a közép- és felsőkategóriás 
készülékek jobb megkülönböztetése, pl. Android Light vagy Android Gold jelzések használata. 

Az itt vázolt okok a platform fragmentációjához vezetnek, ami lassítja az új funkciók terjedését, 
hiszen a fejlesztők kénytelenek korábbi platformverziót célozni, hogy maximalizálni tudják a kom- 
patibilis eszközök számát. Az egyetlen kiútnak az tűnik, ha a Google-nek sikerül az eszközgyártókat 
érdekeltté tenni a korábban eladott készülékeik támogatásában. 


6. Kitekintés a jövőbe 


Az biztosnak látszik, hogy az Android helyzete a közeljövőben tovább fog erősödni, különösen az 
új platformverziónak köszönhetően, amely lehetővé teszi, hogy mobiltelefonok mellett hamarosan 


89 


7 А$7ЕЕВ7ОЕОГ, 





tv-készülékeket és set-top boxokat is célozzunk alkalmazásainkkal. 

Hogy innen merre vezet az út, még elég homályos. Egyelőre úgy tűnik, hogy az Android nem 
fogja leváltani az általános célú operációs rendszereket, mint a Windows, Linux vagy a Mac OS X. 
Ugyanakkor az átlagfelhasználók, akik főleg internetes alkalmazásokat használnak, egyre kevésbé 
igénylik ezeknek a rendszereknek az extra szolgáltatásait. 

Szintén a Google-nél fejlesztik a Chrome OS-t, amely kizárólag ilyen webes alkalmazások fut- 
tatására képes. Középtávon várható, hogy a két projekt egyesül, hiszen mindkét rendszer ugyanazt a 
szegmenst célozza, és egyesítve erőiket jobb felhasználói élményt nyújthatnának. 

Az Android fontosságát jól mutatja, hogy bekerült a beágyazott chipsetek kötelezően támoga- 
tandó operációs rendszerei közé a Linux és a Windows CE mellé. 

Egy biztos: az Android szerepe a belátható jövőben továbbra is meghatározó lesz. 


7. А szerzőről 


A MattaKis Consulting alapítója és ügyvezetője. Az elmúlt években mobiltelefonoktól a Ј2ЕЕ vál- 
lalati alkalmazásokig számos projektben volt fejlesztő, architekt és projektvezető. 14 éve Linux fel- 
használó és fejlesztő. Aktív támogatója a nyílt forráskódnak, korábban a Linux-felhasználók Magyar- 
országi Egyesületében, most a Magyar Android Közösségben. Feleségével és kisfiával Dunakeszin 
él. 
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2 A TROLLTECHTŐL А NOKIÁN KERESZTÜL А NYÍLTSÁGIG 





1. Előszó 


A KDE a három nagy asztali környezet egyikeként él sokak szemében, mára azonban jóval többé vált 
15 évvel ezelőtti önmagához képest. Nem csak egységes környezetet nyújt az ablakkezeléstől kezdve 
a felhasználók igényeit lefedő alkalmazásokig, hanem különböző eszközökre optimalizált munkate- 
rületeket és fejlesztői platformot is. Fejlődése azonban mindig is függött a Ot keretrendszertől, amely 
a KDE alapját adja, és kezdetben még csak nem is volt szabad szoftver, szemben a GNOME-mal. 
Később azonban ez megváltozott, a Ot jelentős fejlődésen ment át nem csak a képességeit, hanem a 
fejlesztési modellt is tekintve. Ahogy korábban szó volt róla, a Ot és a KDE mindig is összefonódott, 
ezért nem lehet úgy beszélni az egyikről, hogy ne ejtenénk szót a másikról is. A továbbiakban tehát 
áttekintés következik a Ot történetéről, majd a 2012-ben érkező következő főverziójáról, végezetül 
rátérünk a lényegre, azaz a KDE jövőjére. 

Mi is a KDE jövője? A kérdés talán homályos első hangzásra, sokféle elképzelés születhet az Ol- 
vasó fejében a cím mögött lévő tartalomról, íme hát egy kis pontosítás: a Ot történeti áttekintése után, 
abból kiindulva bemutatásra kerül néhány azok közül a fejlesztések közül, amelyek vagy már elkezd- 
tek beérni, vagy még csak folyamatban vannak. A KDE hatalmas rendszer, a több mint másfél millió 
kódsor egyes területei stagnálnak, mások fokozatosan fejlődnek, megint mások radikális irányváltá- 
son mennek keresztül, és újak is csatlakoznak. A számítástechnika világa folyamatosan változik, új 
kihívások jelentkeznek, amelyekre a KDE fejlesztői igyekeznek megoldást nyújtani, ilyen kihívás 
például a tabletek és okostelefonok robbanásszerű elterjedése, melyre adott válasz a Plasma Active. 
Hogy a személyi és hordozható számítógépek se maradjanak ki, utolsó témaként szó lesz az idén 


ze 


tizenkettedik születésnapját ünneplő Kwin ablakkezelőről. 


2. A Trolltechtől a Nokián keresztül a nyíltságig 


A Ot fejlesztése 1991-ben kezdődött az akkor még Ouasar Technologies nevű cégnél, amelyből 
később a Trolltech lett. Kezdetben csak Unix X11 és Windows platformokra készült el, utóbbira 
zárt licenc alatt, ami azt jelentette, hogy a UNIX-ra készített szabad és nyílt forrású alkalmazásokat 
nem lehetett portolni Windowsra a licenc megvásárlása nélkül. A Ot 2.2 2000-es megjelenése volt 
az egyik fontos mérföldkő, nem kereskedelmi felhasználásra ugyanis ekkortól volt elérhető GNU 
GPLv2 licenc alatt, addig csak egy ezzel nem kompatibilis licenc (QPL, Q Public License) szerint 
volt szabadon használható, amelyet a Free Software Foundation elutasított, ami egyben azt is jelen- 
tette, hogy az alapítvány a KDE-t nem tekintette szabad szoftvernek. Ezért egyezség születetta KDE 
és a Trolltech között: ha 12 hónapon keresztül nem jelenik meg új szabad/nyílt forrású verzió a Ot- 
ból, az egyezség által létrehozott KDE Free Ot Foundation egy BSD-stílusú licenc alatt kiadhatja a 
Ot forráskódját. 2005-ben a Ot 4.0 megjelenésével a windowsos változat is a GPL licenc hatálya alá 
került, vagyis a kereskedelmi és a szabad változat végre ugyanazokat a platformokat támogatta. 

A Nokia 2008-ban vásárolta fel a Trolltechet, a Ot fejlesztése során pedig arra koncentrált, hogy 
az általa gyártott eszközök fő fejlesztési platformja legyen. A forráskód innentől kezdve a Gitori- 
uson keresztül volt elérhető, a fejlesztést azonban még mindig a Nokia végezte házon belül. Idén 
januárban azonban bejelentették, hogy felsőkategóriás telefonjaikon a Microsoft Windows Phone 7 
rendszert használják a korábban kiválasztott, az Intellel közösen fejlesztett MeeGo helyett. A sza- 
bad szoftveres közösség azon nyomban felbolydult, hiszen a bejelentés megkérdőjelezte a Nokia 
és a Ot viszonyát, a Nokia azonban kiállt a Ot mellett, és Symbian-alapú telefonjain továbbra is 
használja, illetve megjelentették az N9-et, az első és utolsó telefont, amely a MeeGo 1.2 Harmattan 
rendszert alkalmazza. Még egy további fontos dolgot is bejelentettek: nyílttá teszik a Ot fejlesztését 
még 2011-ben. Ez lett a Ot Project, amelyről az alábbiakban lesz szó. 
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2.1. A Qt Project 


A Ot Project meritokratikus, konszenzus-alapú közössége mindazoknak, akik érdekeltek a Ot fejlesz- 
tésében. Bárki csatlakozhat a közösséghez, részt vehet a fejlesztésben és a döntési folyamatokban. 
Habár a Nokia hívta életre a Ot Projectet, és a közösség tagjainak nagy részét szintén a Nokia adja, 
a közreműködők 15-20%-а már most külsős, például más cég alkalmazottja. A közreműködőknek 
öt szintje van, attól függően, hogyan és mivel járulnak hozzá a projekthez. A legalacsonyabb szint a 
felhasználóké (Users), ők azok, akik blogjukban írnak a projektről, visszajelzéseket küldenek, vagy 
csak egyszerűen megköszönik a fejlesztők munkáját. Belőlük lehetnek a közreműködők (Contribu- 
tors), akik már a tényleges fejlesztést végzik, kezdve a dokumentációírástól a hibajavításon át a 
közösségi munkáig és az új felhasználók támogatásáig. Egy Contributor azonban nem közvetlenül 
fejleszt, hanem javításokat küld, amelyeket azután a következő szint, az Approver néz át és fogad el. 
Ők azok, akik kivételes esetben közvetlenül módosíthatják a kódot, ez azonban nagyon ritka, például 
fordítási hiba esetén fordulhat elő. Az utolsó előtti szint a karbantartóké (Maintainers), akik a Ot egy- 
egy részmoduljáért felelősek. Fontos, hogy jól rálássanak a Contributorok és Approverek munkájára, 
folyamatosan készen kell állniuk egy esetleges béta kiadásra. A karbantartók részt vesznek a döntési 
folyamatokban, elfogadhatják az irányítási modell változtatásait, kezelik a közösségen belüli vitákat, 
valamint átnézik azokat a javításokat, amelyeket senki más nem nézett át. A legfelső szintet a Chief 
Maintainer személye képviseli, ő határozza meg a projekt irányvonalát, és hoz döntést azokban a vi- 
tákban, amelyekben sem a közösség nem tudott konszenzusra jutni, sem a karbantartók nem jutottak 
megoldásra. 

A Ot Project honlapja október 19-én indult, itt található a wiki, a levelezőlisták, a hibakövető 
rendszer, a Gerrit forráskód-áttekintő segédeszköz és sok-sok más, a projekthez kapcsolódó doku- 
mentáció vagy jogi nyilatkozat. Az új, nyílt fejlesztési modell első eredménye a valamikor 2012-ben 
megjelenő Ot 5 lesz, amely nem hoz olyan radikális váltást, mint 2005-ben a Ot 4 a Ot 3 után. 


2.2. A trendek követése: Ot 5 


Hat éve jelent meg a legutolsó Ot főverzió, ez idő alatt pedig sokat változott a világ. A mobil esz- 
közök száma óriási mértékben megugrott, az okostelefonok és tabletek új kihívásokat állítanak a 
fejlesztők elé. Azért, hogy ne maradjon le a versenyben, a Ot-nak is meg kell újítania önmagát, és 
bár a Ot 5 tervezése a nyílt fejlesztési modell bevezetésével együtt zajlott, már május óta tudni, me- 
lyek a fejlesztések fő irányvonalai. Az alapokat a már most is meglévő technológiák adják, mint a 
Qt Quick, QML Scenegraph és a Project Lighthouse. Melyek a fő célok? 


e A grafikus processzorok jobb kihasználása, hogy korlátozott erőforrások mellett is gördülé- 
keny és hardveresen gyorsított grafikus megjelenítést nyújthassanak 


e Az alkalmazások és azok felhasználói felülete fejlesztési idejének radikális csökkentése és 
egyszerűbbé tétele a OML és JavaScript segítségével 


e Az alkalmazások és a web lehető leghatékonyabb összekapcsolása például webes tartalmak és 
szolgáltatások beágyazásával a Ot alkalmazásokba 


e A portok elkészítéséhez és karbantartásához szükséges komplexitás és kód csökkentése 


A Ot 4.x a mai napig tartalmaz olyan kódokat, amelyek megakadályozzák, hogy a Ot legyen a 
lehető legalkalmasabb keretrendszer a következő generációs alkalmazásokhoz és felhasználói felüle- 
tekhez. A Ot 5-ben ezeket hátrahagyják, és célzott módosításokat hajtanak végre az alkalmazásprog- 
ramozói felületben (API, Application Programming Interface). Azoknak sem kell aggódni, akik még 


93 


3 A JÖVŐ MÁR ITT VAN 





emlékeznek a Qt 3—Qt 4 váltásra: ezúttal nem ismétlődik meg ugyanaz, a forrásszintű kompatibi- 
litás az esetek nagy részében megmarad, a fejlesztők azonban hiszik, hogy a bináris kompatibilitás 
megtörésére szükség van, de törekednek arra, hogy az átmenet minél simább legyen. 

Szemben az eddigiekkel, a Qt 5 csak a platformok egy szűk halmazára koncentrál első körben 
(Linux/Wayland, Linux/X11, Windows, Mac), később azonban a közösségen múlik, hogy lesznek-e 
további támogatott platformok. Ezzel együtt a most még támogatott platformok egy részének (pél- 
dául a kereskedelmi UNIX rendszereknek, mint a Solaris 10 UltraSparc, AIX 6, stb.) támogatása is 
megszűnik. A cél az, hogy minden platformon a lehető legjobb funkcionalitást biztosítsák, és ebben 
sokat segít, ha kevés platformot kell támogatni. 


2.3. А jövő víziója 

A Qt 5 középpontjába a Qt Quick fog kerülni. Habár a hagyományos C/C++ alkalmazások továbbra 
is működni fognak, a fejlesztők azt várják, hogy a Qt 5-től kezdve minden felhasználói felületet 
ОМІ еп írnak, az alkalmazás logikája pedig JavaScriptben készül, és csak kivételes esetben hasz- 
nálnak C/C++ kódot. A kompatibilitás érdekében ugyan megmarad a OWidget-alapú programozási 
modell és API, hosszú távon azonban a OML fogja leváltani. A KDE már most elkezdte az áttérést 
OML-re, az egyik lépés a Plasma Active, a másik pedig a plazmoidok átírása OML-re, valamint a 
QML felhasználása a KWin ablakkezelőben. 


3. А jövő már itt van 


Tizenöt éves története során a KDE mindig akkor váltott főverziót, amikor a Ot. A legutóbbi ilyen 
váltás 2008-ban történt, amikor megjelent a KDE 4.0, amelyet óriási viták öveztek, hiszen még a 
fejlesztők szerint sem volt kész, sokan pedig máig siratják a KDE3-at, azt állítva, a KDE4 még 
mindig nem érte utol tudásban és minőségben. Hogy ez így van-e, az komoly vita tárgyát képezné, 
koncentráljunk inkább arra, mit tartogat a KDE számára a Ot 5, és mit tartogat a felhasználóknak a 
KDE. 


3.1. Ez már a KDE5? 


2008-ban vált híressé az a mondat, miszerint ez még nem a KDE4. A KDE 4.0 megjelenésekor rájuk 
zúduló kritikák hatására jelentették ki ezt a fejlesztők, akiket kettős kényszer szorított: ahhoz, hogy 
szélesebb réteg tesztelje rajtuk és néhány kíváncsi érdeklődőn kívül, stabilnak nyilvánított kiadás 
kellett, viszont ha kiadnak ilyet, akkor szükségszerűen mindenki azonnal használni akarja, nem tö- 
rődve azzal, hogy még nincs kész minden. A KDE 4.0 körül gyorsan kialakult a 22-es csapdája: az 
alkalmazásfejlesztők kivártak, hogy még fejlődjön, és többen használják, a felhasználók pedig arra 
vártak, hogy kedvenc alkalmazásaik új kiadásai megjelenjenek. 

Ennek megismétlődését szeretnék mindenáron elkerülni, a már készülő KDE Frameworks 5.0 
ezért nem hoz olyan alapvető változásokat, mint a KDE4: a Ot 5-höz hasonlóan inkább a modulari- 
záció, a függőségek letisztázása és a minőség javítása az elsődleges cél, vagyis ugyanúgy megmarad 
a forrásszintű kompatibilitás, de a bináris kompatibilitás mindenképpen megtörik. Ha történik is va- 
lami változás, ami alkalmazás módosítását igényli, az a lehető legkisebb lesz, és automatikus megol- 
dást készítenek rá , hogy a fejlesztőnek minimális erőfeszítésébe kerüljön azt alkalmazni, az esetek 
többségében azonban elég lesz újrafordítani az adott alkalmazást, és tesztelni, hogy megfelelően 
működik-e. A változások a felszín alatt fognak történni: osztályról osztályra átnézik a KDE- t, és ha 
az adott osztálynak jobb helye lenne a Ot-ban, megpróbálják átmozgatni oda, hogy a Ot használói 
számára is előnyös legyen az adott osztály által megvalósított funkcionalitás. Amennyiben egy osz- 
tályról úgy látják, hogy felesleges, akkor meg fog szűnni, esetleg beolvad egy másik osztályba. Így 
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kisebb, könnyebben karbantartható kódbázishoz jutnak, amelyen belül tisztábbak és egyszerűbbek a 
függőségek. 

Hogy mi várható pontosan a KDE Frameworks 5.0-ban, azt még csak maguk a fejlesztők tudják, 
a fenti, meglehetősen kevés és általános információ is tőlük származik. Az útiterv azonban készen 
áll, és biztosak lehetünk benne, hogy a megfelelő pillanatban minden elénk tárul. 


3.2. A KWin ablakkezelő 


Lássunk most egy olyan konkrét alkalmazást a KDE-n belül, amely szinte egyidős vele, és hasonlóan 
nagy változásoknak néz elébe. A Martin Gräßlin vezette fejlesztőcsapat aktívan dolgozik azon, hogy 
folyamatosan jobb és jobb teljesítményt nyújtson a KWin, amellett, hogy új funkciókat építenek bele, 
vagy egyes funkcióit esetleg más alapokra helyezik. Két példán keresztül kerül bemutatásra a KWin 
fejlesztői munkájának összetettsége: az első felszínes áttekintést ad arról, hogyan készülődnek az 
XII leváltására, a második pedig azt mutatja be, hogyan alkalmazzák a OML-t a KWinben. 


3.3. Túl az Х11-еп: út a Wayland felé 


Az Х11 azokban az időkben készült, amikor még nem létezett személyi számítógép, a felhasználók 
terminálon keresztül kapcsolódtak a szerverhez, és ezen a terminálon jelentek meg a szerver által 
küldött üzenetek, majd az első grafikus felületek. Röviden összefoglalva: az Х11 egy kliens-szerver 
alapú architektúra, amely alapvetően hálózati működésre lett tervezve, a modern disztribúciókban 
azonban a kliens és a szerver egy és ugyanaz. A felépítéséből adódóan azonban kikerülhetetlen, 
az X11 fölötti rétegben helyezkedik el az ablakkezelő és kompozitor, valamint a Plasma Desktop 
(vagy a Plasma Netbook, Plasma Active), amelyek kénytelenek az X11-en keresztül kommunikálni. 
A kompozitor (továbbiakban KWin) azonban már régóta átvette az X11 feladatait, így az mára lé- 
nyegében csak egy proxy a kernel és a KWin között. Nyilvánvaló tehát, hogy jobban járnánk, ha 
kidobnánk ezt a proxyt, és így sokkal letisztultabb felépítést kapunk szemben a mostanival, amely 
ráadásul az X11 létrejöttekor még nem is létező igények miatt számos kényszermegoldást is tar- 
talmaz. Kérdés azonban, mivel helyettesíthetnénk az X11-et? A válasz a Wayland, amelyet az X 
grafikus megjelenítő leváltására hoztak létre 2008-ban, az alapjaitól újratervezett felépítéssel és a 
meglévő technológiákra (Kernel Mode Settings, Graphics Execution Manager) alapozva. A váltás 
azonban hosszú folyamat, amivel még maga a Wayland sincs készen, a szabad szoftveres világ azon- 
ban már elkezdett készülődni. A Compiz és a KWin is hasonló módot választott: az X11-függő 
részeket modulokba szervezik, így nem csak a Wayland, hanem más grafikus kiszolgálók támoga- 
tása is egyszerűen megoldható lesz, hiszen csak meg kell írni az adott grafikus kiszolgálót támogató 
modult. 


A folyamat csak elméletben egyszerű, a gyakorlatban számos kérdés merül fel, az első rögtön az, 
sikeres lesz-e a Wayland? Egyelőre senki sem használja, a lehetséges problémák még ismeretlenek, a 
protokoll nincs teljesen definiálva, nincsenek hozzá ablakkezelők, nincsenek alkalmazások, amelyek 
használják, és kérdéses az illesztőprogram-ellátottsága is. Az X11 olyan tulajdonságai, mint például 
a kliens-szerver alapú felépítés, nagyon is jól jönnek hálózati használat esetén. A Wayland azonban 
sokkal hasznosabb mobil platformokon, ahol nincs szükség az X11-re, ezért a KWin Wayland tá- 
mogatása is elsődlegesen a Plasma Active-ra koncentrál. Martin GráBlin becslése szerint körülbelül 
10-20 év, mire a Wayland teljesen leválthatja az X11-et; addig egymás mellett fog létezni a kettő, 
mind a maga területén. 
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3.4. QML a Kwinben 


A QML a Qt Markup Language rövidítése, ebből már sejthető, hogy ez egy leírónyelv, a korábban 
leírtakból pedig tudható, hogy a Qt alkalmazások felhasználói felületének készítéséhez használják. 
Az elve nagyon egyszerű: a grafikus elkészíti akár egy tervezőprogrammal (Qt Creator, Qt Designer) 
az alkalmazás felhasználói felületét, a fejlesztő pedig JavaScriptben megírja hozzá a logikát, de a 
két szerepkör akár egyesíthető is. A QML nagyon egyszerű és könnyen tanulható nyelv, amelyet 
remekül szemléltet az is, hogy a KDE 4.8-ban a KWin legalább két területen alkalmazni fogja: az új 
képernyőzárolóban és az ablakváltóban. 

A képernyő zárolását jelenleg a Krunner végzi, amely biztonsági szempontból rossz megoldás, 
például egy billentyű lenyomásakor az aktiválódó képernyőn kis időre láthatóvá válnak az ablakok 
, és leolvasható a tartalmuk, mielőtt elsötétülne az egész a feloldó párbeszédablak kivételével. A 
KDE 4.8-ban ezt a feladatot átveszi a KWin, az új feloldó képernyő pedig QML-ben készül. A 
feladat átvétele egyben azt is jelenti, hogy a régi X11 képernyővédőket nem támogatja többé a KWin, 
jó hír azonban, hogy helyettük QML-ben készült képernyővédőket lehet majd használni, amiket 
aztán a közösség megoszthat egymással a kde-look.org és hasonló oldalakon keresztül, hála könnyű 
elkészíthetőségüknek. 

Az ablakváltó effektusok jelenleg szintén C++ nyelven vannak megírva, ami nagyon nehézzé 
teszi az elrendezések módosítását, új effektusok hozzáadását. A QML-nek köszönhetően ez is jóval 
egyszerűbbé válik, akár egy órás munkával is szép elrendezések készíthetők, határt csakis a képze- 
lőerő szabhat. A most meglévő öt effektus mellé továbbiak is bekerülhetnek azoktól felhasználóktól, 
akik éreznek magukban elég késztetést és tehetséget új ablakváltó elrendezések készítésére és bekül- 
désére, hogy aztán a KDE 4.8 megjelenése után sok-sok ember használhassa azokat. 


3.5. Plasma Active: határ a csillagos ég 


„Egy mobil eszköznek többnek kell lennie, mint alkalmazások gyűjteményének. Tükröznie kell azt, aki 
vagy. A Plasma Active megtölti a tableted azokkal az okosságokkal, amelyek támogatják, bármit is 
csinálsz bármikor a vadiúj, érintésalapú Aktivitásokkal" . 


3.6. Ádámtól és Évától: egy kis nevezéktan 


A KDE kezdetben a Kool Desktop Environment rövidítése volt, manapság pedig már egy bonyo- 
lult és összetett ökoszisztéma összefoglaló neve. A kiadási közlemények már nem KDE-ről szólnak, 
hanem KDE alkalmazásokról (KDE Applications), KDE Plasma munkaterületekről (KDE Plasma 
Workspaces) és KDE fejlesztői platformról (KDE Development Platform). A Plasma munkaterület 
nem sokkal korábban két dolgot jelentett: az asztali és nagyobb kijelzővel szerelt hordozható számí- 
tógépekre szánt Plasma munkaasztalt (Plasma Desktop) és a netbookokra szánt Plasma netbookot 
(Plasma Netbook). Ezekhez csatlakozott harmadikként október 9-én a Plasma Active, amely most 
még ugyan szintén csak egyetlen eszköztípusra, a tabletekre szánt felület, ez azonban csak a fejlődési 
folyamat első lépcsőfoka, a cél ennél sokkal nagyobb. 


3.7. Plasma Active One 


Ahogy fentebb is olvasható, a Plasma Active nem egyetlen eszköztípust céloz meg, a támogatott 
eszközök skáláját azonban fokozatosan bővítik, első körben csak Intel-alapú tableteket támogat (We- 
Tab, Intel ExoPC), de már az első bejelentés óta bővült a lista az Nvidia Tegra 2 platformjával, és 
egyesek sikeresen elindították Nokia N9-en is. Maga a Plasma Active nem csak egyszerűen egy fe- 
lület, amelyet optimalizáltak a hordozható eszközökre, sokkal több annál. A Plasma Active összetett 


felhasználói élmény, a már meglévő technológiák felhasználásával és továbbfejlesztésével igényekre 
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szabva. Egyik alapköve az aktivitás, amely régóta ismert és használt а KDE-n belül, első ránézésre 
csak egy virtuális asztal, második ránézésre azonban sokkal érdekesebbé válik. Lényegében olyan 
gyűjtemény, amely az adott tevékenységekhez tartozó alkalmazásokat, fájlokat, kisalkalmazásokat 
fogja össze, legyen szó zenehallgatásról, irodai munkáról vagy képnézegetésről. A Plasma Active- 
ban ezek állnak a középpontban, néhány előre definiált aktivitást nyújtva, hogy már bekapcsoláskor 
azonnal használni lehessen az eszközt, a váltás ezek között pedig egyszerű érintésekkel tehető meg. 

Manapság az Interneten történik minden, a közösségek és a tartalmak megosztása fontos része az 
internetező emberek mindennapjainak. A Plasma Active-ban épp ezért azonnal megosztható bármi- 
lyen tevékenység a Share-Like-Connect segítségével, a zenehallgatástól kezdve az éppen nézegetett 
képig e-mailen keresztül vagy más formában. A Share-Like-Connect használatával a létrehozott ak- 
tivitásainkat másokkal is megoszthatjuk, vagy éppen másoktól tölthetjük le az általuk készített és 
megosztott aktivitást. 

A Plasma Active több, mint a KDE fejlesztőinek egy kísérlete, hogy minél több helyen lehes- 
senek jelen; a basysKom és az open-slx cégek anyagi vagy fejlesztői támogatással segítették a fej- 
lesztést, az Intel pedig ingyen ExoPC-k adományozásával a fejlesztőknek. A Plasma Active-nak 
nem célja kész megoldás nyújtása, bár lehetséges utat mutat, de a jövőbeli gyártókra van bízva, 
hogy a rendelkezésre álló elemekből mit építenek fel. A Linux, KDE és Ot alapoknak köszönhetően 
alkalmazások széles spektruma érhető el készen, legfeljebb az érintés alapú irányításra kell őket 
felkészíteni. 

Mi várható a következő kiadásokban? Természetesen hibajavítások és stabilitást növelő fejlesz- 
tések, de új funkciók is érkeznek. A Plasma Active Two automatikus ajánlási rendszert kap, amely 
a kapcsolódó dokumentumok és információk összegyűjtésében és aktivitásokhoz rendelésében segít. 
A Share-Like-Connect képességeit is bővítik, valamint továbbfejlesztett gyűjtemény-megjelenítési, 
-szűrési és -rendezési képességek várhatók a médiatípusokhoz. 

A Plasma Active Three tovább bővíti a támogatott eszközök listáját, például set top boxokkal 
és handheldekkel, de akár autókba épített számítógépekre is telepíthető lesz. Ebben a kiadásban 
kevésbé dominálnak az új funkciók, sokkal hangsúlyosabb szerepet kapnak a biztonságot növelő 
fejlesztések. 


4. Összefoglalás 


Az informatika világa folyamatosan változik, a szabad szoftveres közösségek pedig igyekeznek le- 
követni ezeket a változásokat. Nagyon jó ötletek születnek, és a közösségnek köszönhetően gyorsan 
meg is valósulhatnak, de hogy mennyire terjednek el, az már nehezebb kérdés. Nagy átalakulás 
zajlik a számítástechnikában, a szabad szoftveres közösségeknek gyorsan kell reagálniuk, hogy ne 
maradjanak le. A KDE megindult ebbe az irányba, igyekszik elkapni és meglovagolni a hullámokat. 
Nehéz következtetéseket levonni, hiszen az eddigiek alapján nagyon ígéretes szoftvereket és rendsze- 
reket készítenek, de a gyártókon is múlik, mennyire terjednek el. Reménykedjünk, hogy ha a Linux 
desktop éve nem is jön el talán soha, a szabad szoftver éve elérkezik. 
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2 NÉHÁNY ALAPVETŐ FOGALOM 





1. Bevezetés 


Az itt bemutatott praktikák a FreeBSD-ben történt fejlesztések során lettek kidolgozva. A cél az el- 
avult regex kód lecserélése volt a C könyvtárban. Fontos követelmény volt az új implementációval 
kapcsolatban az elfogadható licenc, a POSIX szabványnak való megfelelőség, a hatékonyság, az el- 
fogadható memóriahasználat, illetve a különböző karakterkészletek támogatottsága. A teljesítmény 
és a memóriahasználat tekintetében felvetődött, hogy a GNU szoftverek determinisztikus automatát 
használnak pár heurisztikus optimizációval a grep programban, ezért nagyon gyorsak, de bizonyos 
esetekben nagyon sok memóriát fogyasztanak. Ráadásul a GNU grep program heurisztikákkal kike- 
rüli a regex implementációt, ami nagyban növeli a kód komplexitását, ráadásul az így megvalósított 
optimizációkból más program nem részesül, csak a grep. Ezen tapasztalatok alapján fogalmazódott 
meg pár gondolat, hogy hogyan lenne érdemes a FreeBSD új regex implementációját szervezni. Az 
ötlet egyrészt az volt, hogy az optimizációkat magába a C könyvtárba kellene beépíteni, és nem 
az azt használó segédprogramokba, így a kód szervezettebb lenne, és minden segédprogram profi- 
tálna belőle. Másrészt az tűnt logikusnak, hogy vegyünk egy jól megtervezett nem-determinisztikus 
automata alapú implementációt, majd azt lássuk el ezekkel a heurisztikus adottságokkal. Ha nagy- 
részt a hatékonyabb heurisztika algoritmus fut le, és az automata csak kevésszer hívódik, akkor a 
nem-determinisztikus automata teljesítménybeli hátránya mérséklődik, míg a memóriafelhasználás 
továbbra is kedvező marad. Habár ezek az ötletek a GNU grepben csírájukban már léteztek, az előze- 
tes vizsgálatok alapján eddig nem jött létre olyan reguláriskifejezés-implementáció, amely heurisz- 
tikákkal működött volna. A konferencián megtartott előadás és jelen cikk a fejlesztés tapasztalatait 
mutatják be. A kiindulópontot a TRE implementáció jelentette, ez lett heurisztikus adottságokkal 
ellátva. 


2. Néhány alapvető fogalom 


2.1. Miaz a reguláris kifejezés? 


A reguláris kifejezés — röviden regex — olyan szövegminta, amely valamilyen tulajdonságú szöveg 
ír le, pl. az , ab" karakterrel kezdődő 5 hosszúságú szövegrészeket. Ha egy szövegrész megfelel a 
mintának, akkor azt mondjuk, hogy illeszkedik a mintára. Az ilyen mintákat a gyakorlatban hasz- 
nálhatjuk többféle célra, pl. valamilyen bonyolultabb keresésre, vagy validálási műveletre. Például 
konkrétan megadhatunk egy olyan mintát, amelyre az e-mail címek illeszkednek, így ellenőrizhető, 
hogy a beírt e-mail cím helyes formátumú-e. A POSIX szabvány leírja, hogy hogyan épülnek fel 
ezek a reguláris kifejezések. Kettő változatot is definiál, az egyszerű és az összetett reguláris kifeje- 
zéseket. Ezeknek a szintaktikája fellelhető a szabványban, illetve szakkönyvekben is, ezért — illetve 
terjedelmi okokból is — most részletesen nem ismertetjük a reguláris kifejezéseket. 

A POSIX szabvány a reguláris kifejezéseken kívül megköveteli azt is, hogy a C könyvtár támo- 
gassa a reguláris kifejezések mintaillesztését, és definiál egy konkrét API-t is, amelyen keresztül a 
mintaillesztés programozható. 


2.2. Miaz a grep? 


A grep egy parancssoros segédprogram, amely szöveges fájlokban egy megadott mintára illeszkedő 
sorokat keres, azaz tulajdonképpen a keresést valósítja meg a fájlokban. Használata nagyon elterjedt, 
sok feladathoz használható közvetlenül is, illetve szkriptekben is gyakran felbukkan. Sok — a keresést 
befolyásoló — funkciója van. A POSIX szintén megköveteli a grep program jelenlétét az operációs 
rendszerben. 
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2.3. A reguláris kifejezések megvalósítása 


A reguláris kifejezések mintaillesztése leggyakrabban egy automatával van megvalósítva. Az auto- 
mata egy olyan modell, amelynek állapotai vannak, és a bemenet hatására ezen állapotok között 
vált. Az automatáknak két típusuk van: determinisztikus és nem determinisztikus. Az előbbi mindig 
egyszerre egy állapotban tartózkodik, míg az utóbbi lehet egyszerre több állapotban is. Általánosság- 
ban elmondhatjuk, hogy a determinisztikus automaták gyorsabbak, de több állapottal rendelkeznek, 
ami nagyobb memóriafelhasználást is jelent. Extrém esetekben az n állapotú nem determinisztikus 
automata determinisztikus megfelelője 2" állapottal is rendelkezhet. Ez sokszor már túl nagy me- 
móriafelhasználást jelent. A nem determinisztikus automatáknál nincs ilyen probléma, de ezek nem 
olyan hatékonyak. 


3. Egy ötletes megoldás: GNU grep 


A GNU projekt grep implementációja az évek során sok tapasztalatot halmozott fel, amelyek a min- 
taillesztés megvalósításánál nagyon hasznosnak bizonyulnak. Azonban azt is hozzá kell tennünk, 
hogy a grep a reguláris kifejezések használatának egy példája, de nem minden alkalmazható általá- 
nos esetben. 


3.1. Néhány programozási best practice 


Az alapvető megközelítés, amit a GNU grep alkalmaz, arra épül, hogy egy program akkor lehet 
igazán gyors, ha a minimálisra korlátozza az elvégzendő feladatokat. Ez jelen esetben több dolgot 
jelent. 

Először is, ahol csak lehet, kerüljük el a másolást. Ne keressünk sortöréseket, és ne másoljuk át 
külön pufferbe a sorokat. Csak akkor foglalkozzunk a sortörésekkel, ha már találtunk egy illeszke- 
dést, mert elég ezután elkülöníteni az illeszkedő sort. Ez alól egy kivétel, ha meg kell számolnunk 
a sorokat, és tudnunk kell, hogy melyik sorban volt az egyezés. A sortörések keresése azt is ered- 
ményezné, hogy a bemeneti szöveg minden egyes karakterét fel kell dolgoznunk, még ha egyébként 
erre nem is lenne szükség. Ezért a sortörések vizsgálatát érdemes elhalasztani az utánra, hogy meg- 
találtuk az illeszkedést. 

Másrészt, ha hagyományos NUL-végű karakterláncokat használunk, akkor ugyanarra a problé- 
mára jutunk mint az előző esetben: karakterenként kell feldolgoznunk a bemeneti szöveget, hogy 
megtaláljuk a záró NUL karaktert. Ehelyett egy jobb ötlet, ha számon tartjuk a pufferünk hosszú- 
ságát, mert így adott esetben nagyobb ugrásokat is el lehet érni. Sajnos a POSIX API függvényei 
NUL-végű karakterláncok, tehát el kell térnünk a szabványtól ahhoz, hogy hatékonyak lehessünk. 


3.2. Heurisztikus közelítés 


A GNU grep a megadott reguláris kifejezésnek, vagy kifejezéseknek veszi a leghosszabb olyan ré- 
szét, amelynek egy az egyben szerepelnie kell a szövegben, majd a Boyer -Moore illetve a Com- 
mentz — Walter algoritmusok egyikével — attól függően, hogy egy vagy több mintánk van — megke- 
resi az első illeszkedést. Ezek olyan algoritmusok, amelyek fix szövegrészt keresnek hatékonyan egy 
bemeneti szövegben. Ezután a GNU grep különválasztja az illeszkedő sort, majd ezen a soron a de- 
terminisztikus automatát is lefuttatja. Ez a módszer a gyakorlatban nagyon gyors, de látható, hogy 
ha pl. minden sor illeszkedne, akkor ez teljesítményromlást jelentene, mert akkor az automata és a 
heurisztika is lefutna minden soron. Ez a megoldás tehát nem mindig hatékony, de a gyakorlatban 
jól bevált. Az általános megoldásban is erre törekszünk. 
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5 AZ ÁLTALÁNOS MEGOLDÁS 





4.  Szövegkeresési algoritmusok 


Mielőtt továbblépnénk az általánosan működő megoldások felé, ejtsünk pár szót a szövegkeresési al- 
goritmusokról, konkrétabban most azokról, amelyek egyetlen mintát keresnek a bemeneti szövegben, 
mint pl. a Boyer— Moore algoritmus. Ezek az algoritmusok tipikusan hátulról kezdik az összehason- 
lítást, majd eltérések esetén, az eltérés típusától függően adott karaktert ugranak előre. Kezdetben az 
algoritmus tehát a mintát a szöveg kezdetéhez igazítja, majd megnézi, hogy az utolsó betű egyezik-e, 
majd az utolsó előtti stb. egészen addig, amíg a minta első karakteréig el nem érkezünk. Ha elté- 
rés van, akkor pedig nem is megy végig az összehasonlítás, mivel a korábbi karaktereknek nincs 
jelentősége, hanem tovább csúsztatjuk a mintát és újra kezdődik az összehasonlítás. 


A Boyer- Moore algoritmusnál kétféle ugrási módszer van, ezek közül mindig a maximálisat 
vesszük. Az első a , bad character shift", ami azt teszi, hogy ha x helyett y betű állt a bemenetben és 
a mintának az elejében van y betű, akkor azt odaigazítja a megfelelő ugrással, ha pedig nincs ilyen 
betű, akkor átugorja. A másik módszer a , good suffix shift", ami pedig úgy működik, hogy ha pl. 
az eltérés után következő rész szerepel a mintában, de előtte nem olyan betű áll, mint ami épp jött, 
akkor ehhez igazítja a mintát, mivel ott potenciálisan egyezés lehet, azaz a helyes utótaghoz igazít. 


A Boyer- Moore algoritmus egyik változata a Quick Search algoritmus, ami ugyanígy működik, 
de csak az első módszert használja ugrásra. Ezt könnyebb is kiszámolni, és így egyszerűbbé válik a 
kód, viszont hatékonyságából nem veszt sokat. 


Ennek az utóbbi algoritmusnak az előnye még, hogy könnyen adaptálható úgy, hogy a reguláris 
kifejezésekben használt , joker" karaktert, a pontot is kezelje, habár az utolsó pont helye limitálja 
a maximálisan lehetséges ugrást, így romlik a hatékonyság. Sean C. Farley implementált egy ilyen 
megoldást a freegrep nevű grep változatban. 


5. Az általános megoldás 


Szóba került korábban, hogy a POSIX API betartásával sajnos nem lehet kihasználni az említett op- 
timizációkat, mivel akkor a feldolgozás karakterenként történik. Szerencsére a TRE implementáció 
rendelkezik egy alternatív API-val, amely alig tér el a szabványtól, de ezeknek átadhatjuk a karak- 
terláncok hosszát is, így nem kell azt végigolvasni a lezáró NUL karaktert keresve. Ezen kívül a 
REG STARTEND nem szabványos flag használata — amely a BSD rendszereken létezett, és jelen 
munka részeként a TRE-hez is elkészült — esetén sem kell végigolvasni a szöveget, mert a megadott 
offszetekből kiszámolható a szöveg hossza. 


5.1. Miért nem működik egy az egyben? 


A grep segédprogramban soronként keressük az egyezést, vagyis az illeszkedő részek nem tartal- 
mazhatnak sortörést. Amikor a leghosszabb fix részt megtaláljuk, akkor ezért, amikor meghívjuk 
lefuttatjuk az automatát, már csak az előző sortörésig kell visszamennünk, és csak a következő sor- 
törésig kell futtatnunk azt. Általános esetben ez nem működik, mert az egyező részben lehet sortörés 
is, tehát a sor elejétől kellene kezdenünk a keresést. Azonban ezt az ötletet fenntarthatjuk arra az 


esetre, amikor a mintát a REG NEWLINE flaggel dolgozzuk fel, mert ez ugyanezt eredményezi. 


Ezen kívül a GNU grep több minta esetén először a Commentz — Walter algoritmussal közelít, a 
POSIX API pedig egyszerre egy mintával dolgozik. Be lehetne erre is vezetni valamilyen alternatív 
interfészt, de jelenleg ez nem célja a projektnek. 
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5.2. Prefix heurisztika 


Hogy behatároljuk tehát a potenciális illeszkedés kezdetét, azaz kizárjuk az azt megelőző részeket, 
kézenfekvő, hogy ne a leghosszabb fix részt, hanem a kezdeti fix részt használjuk. Ha ez a heurisz- 
tika találatot eredményez, akkor ennél előbbre már nem kell visszamennünk. Ez csak akkor nem 
működik, ha már az első karakter is többféle lehet, vagy opcionális. 

Az ilyen fajta heurisztikára példa lehet az int[13][62] t minta esetén az int keresése. De ha а 
minta u?int[13][62] t akkor jelen esetben nem tudunk semmit sem tenni, továbbra is az automatát 
kell használnunk. 


5.3. Fix hosszú heurisztika 


A korábban tárgyalt általánosítások alapján az is elképzelhető lenne, hogy a nem fix részeket ponttal 
helyettesítsük. Ezt mindaddig megtehetjük, amíg fix hosszú karaktersorozatot reprezentálnak. РІ. 
int[13][62] t helyett kereshetünk int.. t, de int[0-9]*_t esetén ezt már nem tudjuk megtenni, mert a 
* karakter miatt az adott részen különböző hosszúságú szövegrészek egyaránt illeszkedhetnek. Ez 
a heurisztika pontosabb, tehát kevesebb , false positive" fordulhat elő, azaz kevesebbszer kellhet 
futtatni az automatát, de ugyanakkor a pontok lecsökkentik a maximális ugrást. A gyakorlatban 
dönthető el, hogy melyik módszer tűnik hatásosabbnak. 


5.4. Heurisztika tömb 


Ennél még egy lépéssel továbbmehetünk úgy, ha megkeressük az összes fix szövegrészt, és ezeket 
eltároljuk egy tömbben, majd egymás után keressük ezeket a bemenetben. Így ráadásul pontosabb 
is lesz a heurisztikánk, mert ha egy rövid prefix talál egy „false positive” egyezést, attól még lehet, 
hogy a további minták kiszűrik azt, így az automata kevesebbszer hívódik meg. Elképzelhető az a 
megoldás is, hogy a prefix és suffix között csak a leghosszabb köztes mintát vesszük figyelembe, 
amivel így a legnagyobb ugrások érhetőek el. Ezek a minták tartalmazhatnak pontot, vagy lehetnek 
teljesen fix minták is. 


6. Konklúzió és távlati kilátások 


A fejlesztés még mindig folyamatban van, de mostanra már bebizonyosodott, hogy a módszer mű- 
ködőképes. Az eddigi mérések azt mutatták, hogy általában a mohó megközelítés hatékony a gya- 
korlatban, azaz amikor az éppen legnagyobb lehetséges ugrásokra törekszünk. Sok esetben 40— 80% 
közötti teljesítményjavulást is sikerült elérni. Hátra van még sok tesztelés, illetve pár módszer kipró- 
bálása is. Ezen kívül a profiling is segíthet a kritikus részek megtalálásában és további optimizálá- 
sában. Jelenleg a kód még nem került be se a FreeBSD-be, se a hivatalos TRE kiadásba. A távlati 
tervek szerint a FreeBSD mindenképp felhasználja majd a kódot, a TRE eredeti szerzőjével pedig 
a cikk szerzője egyeztetni fog arról, hogy hogyan lenne lehetséges beolvasztani a kódot az eredeti 
kiadásba, hogy a szélesebb felhasználói tábor is profitáljon ebből a fejlesztésből. 


7.  Köszönetnyilvánítás 
A cikk szerzője köszönetet kíván mondani Mike Hartelnek, a GNU grep eredeti szerzőjének, aki 
megosztotta azon tapasztalatait, amelyeket a GNU grep fejlesztése során szerzett, Sean C. Farley- 


nek, akinek a freegrepben alkalmazott ötletei kiindulási pontként szolgálhattak, Ville Laurikarinak, 
amiért egy ilyet jól átlátható és jól átgondolt szoftvert készített, mint a TRE, valamint Xin Linek, 
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aki а szerző FreeBSD fejlesztői közösségbe való beilleszkedését segítette, mint mentor. Szintén kö- 
szönet illeti azokat, akik bármi módon, ötlettel, teszteléssel, hibajavítással hozzájárultak az eddig 
fejlesztésekhez. 


Nyílt kormányzat, , zárt ablakok"? 


Dr. László Gábor 
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2 A NYÍLT FEJLESZTŐI MODELL HATÁSAI 





1. Bevezetés 


„Az e-kormányzat következő generációjának két követelmé- 
nye van: az interoperabilitás és az átláthatóság. Ez a kettő 
tulajdonság az erőssége a nyílt forráskódú szoftvereknek." 


Michel Sapin (2001) francia közigazgatási miniszter 


A nyílt kormányzat kérdésköre, hasonlatosan a nyílt szoftverekhez, több kérdést vet fel, mint amennyit 
egy előadás keretén belül meg lehet válaszolni. A nyílt fejlesztői modell, párhuzamosan az IKT esz- 
közök fejlődésével és azok konvergenciájával hatást gyakorol(t) mindennapi életünkre is. A Web2 
modellje átalakította a kultúrát és az állampolgárok politikai részvételét is a döntéshozatal folyama- 
tában. A nyílt forráskód modellje nemcsak a szoftvervilágban és a tudásintenzív gazdasági életben 
hozott jelentős változásokat, hanem a politikai életben is kezdi éreztetni közvetlen hatását. 

Az előadás célja — a teljesség és a definitív megfogalmazások nélkül – a nyílt kormányzat komp- 
lex jelenségkörének, hátterének, fejlődési irányainak bemutatása. 


2. A nyílt fejlesztői modell hatásai 
„А demokrácia az első nyílt forráskódú alkalmazás." 


Phil Windley 


Milyen problémákat oldhatunk meg a nyílt együttműködés modelljével? Milyen módon befolyá- 
solja a tanulásról, a munkáról, a kormányzatról/kormányzati munkáról alkotott elképzeléseinket? A 
nyílt forráskód fogalma a szoftver forráskódjára, az együttműködés modellje pedig arra utalva jött 
létre, hogy hogyan fejlesztik ezeket a szoftvereket. A nyílt forráskód alapelvei: nyíltság, átlátható- 
ság, együttműködés, változatosság. A nyílt forrás több mint szoftverfejlesztési modell, leírja napjaink 
kultúrájának jellemzőit, az ötletek és az erőfeszítések megosztását, együttműködést és nem elszigete- 
lődést jelent. A jelenség azonban már régen túlmutat a technológián, a szoftver forráskódján. Hatása 
exponenciálisan növekszik az élet minden területén. 

A nyílt modell legújabb alakváltozatát a tömeges részvétel és az együttműködés jellemzi, túl- 
lépve a fejlesztői közösségeken. A fogalmat , wikinomics" — a magyar nyelvű fordítása , wikinómia" 
— Don Tapscott 2006-ban megjelent könyve kapcsán vezette be. A technológiai forradalom, a demo- 
gráfiai, a társadalmi és a gazdasági változások együttesét hívja így. A wikinómia alapelvei a nyíltság, 
az egyenlőség, a részvétel és a globális gondolkodásmód [Tapscott 2006]. A tömeges együttműkö- 
désre épülő modell megváltoztatja a gazdaságot, a társas kapcsolatokat, az információáramlást, a 
tudásmegosztást és még a kormányzati szervezeteken belül is érezteti hatását. A közösségi oldalak 
és a Wikipedia megjelenése és gyors növekedése, valamint a , wiki", mint technológia elterjedése 
és intenzív használata jellemzi a Web2-ként is említett korszakot. [Kelty 2008] szerint a végbemenő 
változásokat a szabad szoftverek megjelenésének és hatásainak szemszögéből lehet megérteni. 

Az együttműködés új korszaka, a 2.0-val jellemzett korszak nem igazán technológiai, hanem 
szemléletbeli változást jelent. A Web 2-es alkalmazások analógiájára sok terület változásait jellemez- 
ték az 1.0-s verzióról a 2.0-ás verzióra történő átállással. A változások oka az internet, az internetes 
szolgáltatások változásában keresendő. 

A , nyílt forráskód" modell a szoftvertechnológián túlmutatva demokratizálódási hatásokat is 
kivált. Ez az effektus a fejlett nyugati világban is érezteti hatását csakúgy, mint az ilyen típusú 
szoftvereket előnyben részesítő , Globális Dél" államai esetében. Mindkét esetben más-más típusú 
változásokat segítve elő. 
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A legismertebb és egyik legjelentősebb kezdeményezés а Barack Obama által indított Nyílt Kor- 
mány Kezdeményezés [Open Government Initiative 2009] jelszavai: átláthatóság, részvétel, együtt- 
működés. 


3. A nyílt kormányzat szintjei 


„A szabadságszerető ember — minden felismert közérdek 
ügyében kezdeményezőleg lép fel, minden közérdekű szövet- 
kezésben vagy mozgalomban tehetsége szerint munkájával és 
adományával részt vesz, és igyekszik azt győzelemre segíteni, 
tisztában lévén azzal, hogy a közügyek elhanyagoltsága, vagy 
méltatlan emberek kezébe való kerülése egyedül a tisztessé- 
ges emberek kezdeményezésének hiánya és közéleti bátorta- 
lansága miatt történhetik." 


Bibó István: A szabadságszerető ember politikai tízparancso- 
lata 


A nyílt kormányzat fogalma alatt kezdetben a kormányzati és az állami hivatalok döntési folyamata- 
inak átláthatóságát (nyíltságát) és adatainak hozzáférhetőségét értették. [Perrit 1997] 

A nyílt kormányzat fő témakörei közt szerepel az adatok hozzáférhetősége, a hosszú távú meg- 
őrzés és elérés, az adatvagyon hasznosulása, továbbá az állampolgárok politikai részvétele a döntés- 
előkészítésben, a döntéshozatal kontrollálásában. 


3.1. Szellemi közjavak — Adatvagyon 


A világháló nagyszerű új lehetőségeket teremtett a tudásmegosztáshoz, a kultúra terjedésének új for- 
máihoz, az alkotások megosztásához. Azonban az internet megjelenésével és ezekkel a változásokkal 
a jog nem tudott lépést tartani. Lessig (2005) Szabad Kultúra című művében alaposan körüljárja a 
szellemi tulajdon, a szerzői jog kialakulását és szerepét, a jelenlegi rendszer visszásságait és azo- 
kat a problémákat, amelyeket az internet idézett elő ezen a területen, valamint elemzi a szellemi 
közjavakat is. [Lessig 2005] 

A közszektor az államháztartás, a közszolgáltató vállalatok és a non-profit intézmények összes- 
sége. Funkciója a kollektív javak (közjavak) és a közszolgáltatás biztosítása. A szellemi közjavak a 
közszféra számára különös jelentőséggel bírnak.[Rátai, B. — Szemes, B. (2008)] A közszférán belül 
is átláthatóbb és olcsóbb működéshez vezethetnek, amelyek magukba foglalhatják a nyílt forráskódú 
szoftvereket is. A szellemi közjavak tartománya azonban önállóan is szerteágazó terület. Az előadás 
két kiemelt területtel foglalkozik, a technológiai megjelenítéssel, hosszú távú megőrzéssel, valamint 
a jogszabályi környezettel. 


3.2. Az adatvagyon hozzáférhetősége és hosszú távú megőrzése 


Az UNESCO megfogalmazása szerint: , A világ digitális örökségét a végleges eltűnés veszélye fe- 
nyegeti. Ehhez hozzájárul az azt tartalmazó hardware és software gyors elavulása, bizonytalanság a 
forrásokkal, felelősségekkel, és a fenntartás és megőrzés módszereivel kapcsolatban, valamint a tá- 
mogató jogi szabályozás hiánya. A hozzáállásbeli változások elmaradtak a technológiai változások 
mögött. A digitális fejlődés túl gyorsan és a kormányok és intézmények számára túl költséges mó- 
don ment végbe ahhoz, hogy a megfelelő időben lehessen megőrzési stratégiákat életbe léptetni. Az 
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örökség gazdasági, társadalmi, szellemi és kulturális potenciálját — a jövő építő elemeit — érintő fe- 
nyegetéseket még mindig nem tudták teljesen megragadni." [Charta а digitális örökség védelméről, , 
3. Cikkely — Az eltűnés veszélye] 


3.3. A nyílt szabvány, mint megoldás 


A nyílt szabványok alkalmazása fontos szerepet kap a kormányzatok és kormányzati szervezetek 
által közzétett információk megjelenítése és közzététele terén. Vannak kormányzatok, amelyek por- 
tálokat (például data.gov) hoztak létre, hogy az adatok könnyebben megtalálhatóak legyenek. A 
W3C (World Wide Web Consortium) segítségképpen egy útmutatót jelentetett meg, amelyben sze- 
replő egyszerű lépések kiemelik a szabványok és módszertanok használatát, ezáltal is támogatva a 
kormányzati adatok publikálását és a kormányzati információk innovatív, nagyobb üzleti és közös- 
ségi hasznosítását és újrahasznosítását. Ezeknek az adatoknak a megosztása nagyobb átláthatóságot 
és hatékonyabb közszolgáltatásokat tesz lehetővé. [Publishing Open Government Data] 

A Weben történő megosztáson túlmutatóan az informatika , rövid távú" gondolkodására jól vilá- 
gít rá Erik Kriss, Massachusetts állam közigazgatásért és pénzügyekért felelős miniszterének találó 
megjegyzése, miszerint , az egyik központi kérdés az, hogy miképp biztosítsuk a közadatok operá- 
ciós rendszertől és alkalmazásoktól való függetlenségét hosszú időtávlatban. Az információs techno- 
lógia területén a hosszú táv úgy 18 hónap, a kormányzatban ez körülbelül 300 évet jelent, tehát egy 
kissé különböző távlatban gondolkodunk". [Informal comments on Open Formats n.d.] 

A nyílt szabvány definíciójára számtalan megközelítés létezik. A Nemzetközi Távközlési Egye- 
sület Szabványosítási testülete (ITU-T)! a nyílt szabványokat olyan szabványként definiálja, ame- 
lyek a nagyközönség számára elérhetők, és a kifejlesztésük (vagy az elfogadásuk) és karbantartásuk 
együttműködésen alapuló, átlátható közmegegyezéses eljárással történik, amelyben valamennyi érin- 
tett szabadon részt vehet. A nyílt szabványok, érinthetnek tulajdonosi szabadalmakat. A definíció sok 
vitát generált ezen szabadalmak licencelésével kapcsolatban. Az elfogadható, méltányos és diszkri- 
minációmentes (reasonable and non-discriminatory – RAND) feltételek alatt rendelkezésre bocsátott 
szabványok a nyílt forráskódú közösségek számára — általában — nem fogadhatók el nyílt szabvány- 
ként, de a legtöbb szabványügyi szervezet és testület az ezen feltételeket alkalmazó szabványokat is 
nyílt szabványként kezeli. [Hoe 2006] 

A nyílt szabványra — a definíciók és a különböző megközelítések ötvözésével — az alábbi megha- 
tározást tehetjük: Egy szabványt akkor tekinthetünk teljesen nyílt szabványnak, ha teljesíti az alábbi 
kitételeket: 


e Szabadon megismerhető és használható; 

e Szabadon implementálható, a fejlesztése nyílt folyamat eredménye, bárki részt vehet benne; 
e Független a gyártóktól és szállítóktól; 

e Jogdíjmentes. 


A nyílt szabvány és a nyílt forráskód kapcsolatában a nyílt forráskód a nyílt szabványok érvénye- 
sülését segíti. 

Magyarországon a Parlament 2009. december 14-én 197 igen, 1 nem, 146 tartózkodás arányban 
elfogadta azt a törvényjavaslatot, amely a Nyílt Szabvány Szövetség által javasolt nyílt szabványos 
törvénymódosítást tartalmazta?. (2009. évi LX. törvény az elektronikus közszolgáltatásról) A nyílt 
kormányzás azonban nem csak a technológiai feltételeket foglalja magába. 





lDefinition of „Open Standards", http: //www.itu.int/en/ITU-T/ipr/Pages/open.aspx 
2А törvénymódosítás kulisszatitkai, http ://nyissz.hu/blog/a-torvenymodositas-kulisszatitkai/ 
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4. Jogszabályi környezet 


A jogszabályi környezet is többrétű. Egyrészt, magát az információszolgáltatást foglalja magában, 
másrészt, a keletkezett adatvagyon szerzői jogi szabályozását, főként annak üzleti célú további hasz- 
nosítása esetén. 

Az Eötvös Károly Intézet Az elektronikus információszabadság jogi garanciáinak felülvizsgálata 
című tanulmányának megállapítása szerint, ,, Magyarország példás információszabadság-szabályok- 
kal rendelkezik, szabályozási megoldásai sok más ország számára szolgálnak mintaként. A szabályo- 
zás korszerűsége többek között abban áll, hogy nem az akták, még csak nem is a dokumentumok, 
hanem az azokban szereplő adatok nyilvánosságára koncentrál, függetlenül a hordozójuktól vagy 
az adatok önálló vagy gyűjteményes jellegétől". [. . . ] , Az elektronikus információszabadság alapve- 
tően jó szabályai azonban mégsem érvényesülnek megfelelően. Több felmérés zárult a közelmúltban 
olyan eredménnyel, miszerint a közzéteendő adatok Magyarországon a gyakorlatban csak a törvény 
szerint nyilvánosak, valójában nem megismerhetők”. [...] „Az információszabadság érvényesülésé- 
vel kapcsolatos felmérések azt mutatják, hogy a szabályok a hivatalok nyilvánosság-párti hozzáállása 
nélkül nem sokat érnek" . [Eötvös Károly Intézet 2009] 

Az elsődlegesen meghatározó maga a kormányzat hozzáállása a kérdéskörhöz. Magyarországon 
— jóllehet mindkét program foglalkozik a nyílt kormányzat kérdésköreivel — sem a Digitális Megúju- 
lás Cselekvési Tervben? sem a Magyary Programban! nem szerepel a , nyílt kormányzat" nevesítve. 


5. Nyílt Kormányzat Együttműködés 


Átláthatóság, részvétel, együttműködés a jelszavai az új Nyitott Kormány Direktívának (Open Go- 
vernment Directive), amelyet Barack Obama kampányígéretéhez híven 2009-ben indított az amerikai 
kormány munkájának átláthatóbbá tételére [Memorandum 2009]. A kezdeményezés nemzetközi ki- 
tekintésben a Nyílt Kormányzat Együttműködés programjában csúcsosodott ki, amelyet hivatalosan 
2011. szeptember 20-án indítottak útjára 8 alapító ország (Brazília, Indonézia, Mexikó, Norvégia, 
Fülöp-szigetek, Dél-Afrika, Nagy-Britannia és az USA) részvételével, amely országok jóváhagyták 
a Nyílt Kormányzat Nyilatkozatot, és bejelentették, országaik cselekvési terveit. További 38 kor- 
mányzat jelezte elkötelezettségét az együttműködéshező . 

Magyarország a honlap tanulsága szerint még nem jelezte csatlakozási szándékát az együttmű- 
ködéshez, amelyre civil szervezetek fel is hívták a Kormány figyelmét 2011. szeptember 29-én kelt 
nyílt levelükben. [Nyílt levél Navracsics Tibor részére] 

Annak érzékeltetésére, hogy a nyílt kormányzathoz is hosszú és szisztematikus út vezet, érde- 
mes egy rövid kitekintést tenni annak az országnak a példájára, amely hosszú éveken keresztül ez 
e-kormányzat éllovasa volt és amely a bejelentés napján — 2011. szeptember 20-án — csatlakozott 
a Nyílt Kormányzat Együttműködéshez. A kanadai kormányzat az 1960-as és 70-es években felis- 
merte a lakosság jogát a nyilvános kormányzati adatokhoz való hozzáféréshez. Abban a kérdésben 
is egyetértés mutatkozott, hogy az adatbázisok előállításába és működtetésébe be kell vonni a civil 
szektort, ügyelve arra, hogy a kormányzat tulajdonában és ellenőrzése alatt maradjanak az adatbázi- 
sok. 1993 szeptemberében az Industry and Science Canada közzétette, hogy elindított egy online do- 
kumentációs adatbázist, amelyben minden dokumentum angol és francia nyelven is elérhető ASCII 





3Digitális Megújulás Cselekvési Terv 2010 — 2014, 
http: //www . kormany . hu/download/6/4f£f/00000/Digitalis Megujulas Cselekvesi Terv.pdf 
Letöltve: 2011. október 20. 

4Magyary Közigazgatás Fejlesztési Program, http : / /www . kormany . hu/down1load/1/6d/40000/Magyary 
Kozigazgatas fejlesztesi Program.pdf Letöltve: 2011. október 20. 

5A programhoz kapcsolódó országok listája megtalálható az együttműködés honlapján: 
http://www.opengovpartnership.org/countries Letöltve: 2011. október 20. 


109 


HIVATKOZÁSOK 





formátumban, FTP protokollon, vagy Listserve-n keresztül. A kapcsolódások száma az induláskori 
150 kapcsolat/hétről következő év januárjára 7 000-re emelkedett. Ezt látva a kezdeti 500 dokumen- 
tum helyett az egész adatbázist könnyen hozzáférhetővé, és teljes mértékben kereshetővé tették ja- 
nuárban. Az Internet hasznosságát egyre több kormányzati szerv és hivatal ismerte fel. 1994-ben 
megszaporodott azoknak a teljes szövegű dokumentumoknak a száma, amelyek elérhetővé váltak az 
FTP, Gopher, WAIS, illetve az Internet segítségével. 1994 januárjában a kormány az informatikai 
vezetőik részére egy útmutatót bocsátott ki az információs vagyon (ezzel együtt a technológiák) fe- 
lülvizsgálatára. Ez felölelte az információ egész életciklusát (keletkezés, rendszerezés, tárolás, meg- 
semmisítés stb.). 1994 áprilisában a Pénzügyi Bizottság egy vitaanyagot bocsátott ki, amelynek célja 
a kormányzati szolgáltatások újragondolása volt az informatikai eszközök használatával kapcsolato- 
san. Ezt széles körben terjesztették, várva a visszajelzéseket a kormányhivatalokban dolgozóktól 
éppúgy, mint a lakosságtól. A , látomás" egy egységes kormányzati információs infrastruktúra volt, 
amely felgyorsítja az adatáramlást, csökkenti a duplikációt, jobban és költséghatékonyabban lássa 
el mind a kormányzati munka, mind a lakosság szolgálatát. A kanadai kormány példaértékű modell 
felhasználóvá vált, ezzel is elősegítve az új technológiák mindennapi bevezetését az országban. 1995 
decemberében indították útjára a kanadai kormányportált a www.canada.gc.ca címen, az állampol- 


nez 


gárok jobb kiszolgálása érdekében. Az Industry Canada stratégiai gyűjtőoldalán1997-ben több, mint 
650 000 dokumentum volt online е1ёгһеїб®. 
2011-ben Open Government néven külön gyűjtőoldalt hoztak létre a www.open.gc.ca címen, 


amelyen a nyílt kormányzattal kapcsolatos iniciatívák és információk találhatóak meg. 


6. Zárszó helyett 


Amint azt az előadás bemutatta, a nyílt kormányzat kérdésköre, hasonlóan a nyílt szoftverekhez 
összetett jelenségkör. Hogy nyílt kormányzattal, vagy zárt ablakokkal találkozunk, az nagyrészt a 
kormányoktól függ, azonban az állampolgárok is sokat tehetnek annak érdekében, hogy kitáruljanak 
az ablakok. . . 
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3 NEM HAGYOMÁNYOS KIADVÁNYSZERKESZTÉS? 





1. Bevezetés 


Fernand Vanrie, a belga PMG kiadó főmunkatársa komoly problémával nézett szembe. A szakmai 
magazinokat kiadó cég növekedésnek indult, de az újabb és újabb drága kiadványszerkesztő prog- 
ramok beszerzése túlzásnak tűnt az elvégzendő feladathoz képest. Ekkor került képbe az ingyenes 
OpenOffice.org, a LibreOffice elődje. Némi próbálkozás után alkalmasnak is tűnt a előzetes törde- 
lésre, vagyis a sok kép és szöveg elhelyezésére, levéve ezt munkát a professzionális kiadványszer- 
kesztő válláról. 

Legalábbis ez volt a kiindulási terv, de kiderült, hogy a kidolgozott munkafolyamatban nincs 
szükség kereskedelmi kiadványszerkesztőre. A kiadó azóta is évi mintegy 8000 színes, képes maga- 
zinoldalt készít az OpenOffice.org-gal, ami jó példája az OpenOffice.org, illetve a LibreOffice rejtett 
kiadványszerkesztő képességeinek. Ilyen, a belga kiadó esetében döntő képesség, hogy az Open- 
Office.org/LibreOffice kezeli az EPS (Encapsulated PostScript) képállományokat, így a reklámügy- 
nökségek által készített — bittérképes képeket, vektoros feliratokat is tartalmazó — professzionális 
hirdetési anyagok eredeti nyomdai minőségben kerülhetnek be a magazinokba, nincs szükség ezek 
előzetes bittérképes átalakítására. 

Összevethető-e a LibreOffice a kereskedelmi kiadványszerkesztőkkel? Ha igen, melyek a Lib- 
reOffice kiemelkedő képességei, amellyel versenyképes termékként léphet fel nemcsak a szöveg- 
szerkesztők (dokumentumszerkesztők), hanem a kiadványszerkesztők világában is? Ki tud-e lépni a 
LibreOffice a , fapados" kiadványszerkesztő kategóriából, és ha igen, hogyan? 


2. Mit nevezünk kiadványszerkesztőnek? 


Nyomdai vagy közel nyomdai minőségű kiadványok készítésére szolgáló, grafikus felületű személyi 
számítógépes alkalmazásokat, amelyek a kiadványok többé-kevésbé alakhű! szerkeszthető előnéze- 
tét mutatják. Az asztali, vagyis személyi számítógépes kiadványszerkesztés (desktop publishing — 
DTP) az Apple Macintosh rendszerek egyik sikerének titka volt. Közel nyomdai minőségű kiad- 
ványok készítését tették lehetővé a PostScript lapleíró nyelvre és az azt közvetlenül értelmező, jó 
minőségű (300 dpi-s) LaserWriter nyomtatóra támaszkodva 1985-ben. (A technológiának elválaszt- 
hatatlan része volt a DTP sikerében.) Idővel nemcsak a különböző vektoros betűtípusokkal és tipo- 
gráfiai finomságokra is ügyelő szövegtördeléssel készülő könyvek és egyéb kiadványok tartoztak a 
DTP hatáskörébe, hanem a — jelentős részben a DTP rendszerek fejlődésének köszönhetően egyre 
összetettebb szöveg- és képelrendezését mutató — színes magazinok is. A hagyományos értelemben 
vett DTP ezen a területen éri el a csúcsát, még ha a végtermék nyomdai-tipográfiai színvonala erősen 
szakemberfüggő maradt ma is, hiszen a kiadványkészítés nem nélkülözi az iparművészeti ismerete- 
ket és készséget. 


3. Nem hagyományos kiadványszerkesztés? 


A hagyományos DTP programok nem fednek le minden nyomdai igényt, nagyobb kiadványokhoz 
az Adobe már a Framemakert ajánlja. Telefonkönyvek, lexikonok, napilapok kiadásában is specia- 
lizált nyomdai rendszerek (pl. Datalogics DL Composer, Miles 33, КуТеК Autopage OuarkXPress 
bővítmény, PTC APP, XPP) segítenek, nemcsak a matematikai-tudományos folyóiratok szedésben 
egyeduralkodó a ТЕХ és változatainak használata. Ezekben a rendszerekben közös, hogy esetenként 
a WYSIWYG rovására (ezeket többé-kevésbé mellőzve) nagyobb automatizálási lehetőséget bizto- 


sítanak, többnyire az XML-re támaszkodva. A következőkben a nagyobb kiadványok félig-meddig 





1WYSIWYG — What you see is what you get, magyarítva ALAKHŰ — Azt látod, amit kapsz, hűen. 
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automatizált szedésére mutatunk példát olyan ODFPy Python kódrészletekkel, amelyekkel а teljes 
Biblia került kiszedésre (ezer oldalnyi szöveg 30 ezer lapszéli kereszthivatkozással). Előtte még meg- 
említjük azonban a LibreOffice hagyományos asztali kiadványszerkesztésre jellemző, például a nyílt 
forráskódú Scribus program által is megcélzott képességeit. 


4. Dokumentumszerkesztőből kiadványszerkesztő? 


Ahogy a bevezetőben már említésre került, ma már egy olyan dokumentumszerkesztő, mint a Lib- 
reOffice is be tudja tölteni egy kiadványszerkesztő szerepét, természetesen képességei és a feladat 
függvényében. A mai dokumentumszerkesztők fokozatosan veszik át a kiadványszerkesztők képes- 
ségeit: grafikus felhasználói felület; vektorgrafikus betűkészletek, a betűk egalizálása, komplex szö- 
vegelhelyezés (hasábok, összefűzhető szövegkeretek), vektorgrafikus képformátumok támogatása, 
fejlett betűtechnológia, PDF-kimenet stb. 

A magyar FSF.hu Alapítvány támogatásával megvalósított fejlesztéseknek köszönhetően a Lib- 
reOffice olyan tipográfiai lehetőségeket nyújt alapváltozatában is, amelyek eddig csak a nyomdára 
és a DTP rendszerekre voltak jellemzők, vagy még azokra sem: ilyen a valódi kiskapitálisok, ligatú- 
rák (köztük a magyar fj, #7, gy, gf, efi, gfö, gj kurzív ligatúrák), ugráló számok, valódi nagy és kis 
betűfokozat, magyar csillagos lábjegyzetszámozás stb. támogatása. 

Fontos kiemelni a piacvezető kiadványszerkesztők egyik célkitűzését, a munkavégzés hatékony- 
ságának növelését. Kezdve a billentyűkombinációktól a mesteroldalakon át a GREP stílusokig szá- 
mos ponton biztosítják a mai DTP programok a kiadványszerkesztési feladatok automatizálását. Ez 
egyáltalán nem áll távol a LibreOffice-tól, amely programozhatóságával (makrórögzítő, UNO progra- 
mozási interfész, Basic fejlesztői környezet, beépített Python interpretált nyelv, Java és C++ progra- 
mozási keretrendszerek, kiterjesztéskezelő, beépített és bővíthető XML-szűrők) és alapértelmezett, 
nyílt szabványú, XML-alapú fájlformátumával (OpenDocument) kiemelkedik a dokumentumszer- 
kesztők és a kiadványszerkesztők között is. 


5.  Kiadványszerkesztés LibreOffice Writer szövegszerkesztővel 


A http://www.numbertext.org/libreoffice címen elérhető magyar nyelvű jegyzet bevezetést nyújt a 
LibreOffice Writer és eszközeinek, a betű- és bekezdésformázásnak, stílusoknak, sablonoknak, sőt 
programozási felületének használatába. 


6. Magyar nyelvi és tipográfiai támogatás 


A LibreOffice kifejezetten kiadványszerkesztőkre jellemző tulajdonságai (például fejlett betűtechno- 
lógia, interaktív PDF-elemek támogatása) kiegészül a kiemelkedő magyar nyelvi támogatással: az 
elválasztás és a helyesírás-ellenőrzés több szinten szavatolja a kiadványaink minőségét. A magyar 
névelő automatikus kiválasztása a tudományos kiadványok készítését egyszerűsíti le. A Graphite 
betűtechnológia nemcsak a piacvezető Openlype versenytársa, hanem annál nagyobb rugalmassá- 
got biztosít GDL programnyelvének és gyártófüggetlen megoldásainak köszönhetően. Látványos 
példája ennek a LibreOffice Linux Libertine G és Biolinum G betűkészleteinek alapértelmezett auto- 
matikus ezrestagolása, szóköz helyett a megfelelő keskeny szóközzel. Számos olyan magyar tipográ- 
fiai sajátosságot ismer a LibreOffice, amelyeket a honosított kereskedelmi kiadványszerkesztők sem: 
ilyenek a már említett speciális kurzív ligatúrák, a magyar írásjelekre jellemző térköz az írásjelek 
előtt, a magyar lábjegyzet-csillagozás, illetve a magyar ékezetes betűk egalizálása (ami nemcsak a 
Times New Roman betűtípusból, hanem számos egyéb kereskedelmi betűkészletből is hiányzik). 
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6 MAGYAR NYELVI ÉS TIPOGRÁFIAI TÁMOGATÁS 





1. ábra. Példa a LibreOffice alapértelmezett DTP lehetőségeire 












MÓZES ELSŐ KÖNYVE A TEREMTÉSRŐL И 


*1Мб2 2,4, 1Móz 2,5, Zsolt 33,6, 
Zsolt 89,12, Zsolt 136,5, Csel 14,15, 


élység színén, és az Isten Lelke Sazi 7518 11.3, 765 35.4 
da Isten: Legyen világosság: és 
ön vilagossag. "Es lata Isten, hogy jó a világosság; és elválasztá Is- 
ten a világosságot a setétségtől* "És nevezé Isten a világosságot 






*2Ког 4,6 


жЁѕа 45,7 


nappalnak, és a setétséget nevezé éjszakának: és lőn este és lőn reggel, első nap. 
"És monda Isten: Legyen mennyezet a víz között, a mely elválassza a vizeket a 


vizektől." "Teremté tehát Isten a mennyezetet, és elválasztá a mennyezet alatt va- *° 1012.76 5145 
* Zsolt 148,4 


ló vizeket, a mennyezet felett való vizektől. És úgy lőn" "És nevezé Isten a meny- 
nyezetet égnek: és lőn este, és lőn reggel, második nap. És monda Isten: Gyűlje- 
EA гонаг egy helyre, hogy tessék meg а száraz. És ú 

egal izált számjegyek нес egykegyült а pedig кагы. 
nevezé. És látá Isten, hogy jó (Azután monda Isten: Hajtson а föld gyenge fű- 
vet, maghozó fűvet, gyümölcsfát, a mely gyümölcsöt hozzon az ő neme szerint, 
a melyben legyen néki magva e földön. És úgy lőn. ?Hajta tehát a föld gyenge fű- 
vet, maghozó fűvet az ő neme szerint, és gyümölcstermő fát, a melynek gyümöl- 
csében mag van az ő neme szerint. És látá Isten, hogy jó."És lőn este és lőn reg- 
gel, harmadik пар. "És monda Isten: Legyenek világító testek az ég mennyeze- 
tén, hogy elválasszák a nappalt az éjszakától, és legyenek jelek, és meghatározói 
ünnepeknek, napoknak és esztendőknek* "És legyenek világítókul az ég meny- 
nyezetén hogy világítsanak a földre. És úgy lőn. "Teremté tehát Isten a két nagy 
világító testet: a nagyobbik világító testet, hogy uralkodjék nappal és a kisebbik 
világító testet, hogy uralkodjék éjjel; és a csillagokat? "És helyezteté Isten azo- 
kat az ég mennyezetére, hogy világítsanak a földre; "És hog F a 
nappalon és az éjszakán, és elválasszák a világosságot a setétsé azonos keretstílusú 
hogy jó."És lőn este és lőn reggel, negyedik nap."És monda Is szöveg keretek 

a vizek élő állatok nyüzsgésétől; és madarak repdessenek a Ж к 
mennyezetének színén.” És teremté Isten а nagy vízi állatokat, és mindazokat а 
csúszó-mászó állatokat, a melyek nyüzsögnek a vizekben az ő nemök szerint, 






*Jób 38,8, Zsolt 33,6, Zsolt 33,7, 
Zsolt 33,9, Zsolt 136,6 
*Zsolt 95,5 


























*Zsolt 104,19 


*Jer 31,35 


* Zsolt 136,7, Zsolt 136,9 


magyar térközök 
az írásjelek előtt 





egész földön, és a földön csúszó-mászó mindenféle állatokon? "Teremté tehátjaz M675% Kor 11.7, Kol 310 
Isten az embert az ő képére, Isten képére teremté őt: á 
remté őket. "És megáldá Isten őket, és топ иийй 5 
kasodjatok, és töltsétek Бе a földet és Һајіѕа ligatú ra 

tok a tenger halain, az ég madarain, és a földő 0520278 
Коп. °Ёѕ monda Isten: Imé néktek adok minden maghozó fűvet az egész föld þzí- 
nén, és minden fát, a melyen maghozó gyümölcs van; az legyen néktek eledel 
"A föld minden vadainak pedig, és az ég minden madarainak, és a földön dsú- 
szó-mászó mindenféle állatoknak, a melyekben élő lélek van, a zöld fűveket 
adom eledelűl. És úgy lőn. "És látá Isten, hogy minden a mit teremtett vala, 


igen jó. És lőn este és lőn reggel, hatodik nap. р 2 
optikai margó 







át 19,4, Márk 10,6 


1Móz 9,3, Zsolt 115,16 


Zsolt 104,14 
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A LibreOffice szabad szoftver, ami jelentősen hozzájárult ahhoz, hogy a magyar kiadványszer- 
kesztési igényeknek megfelelően lehetett bővíteni. Ez a már említetteken kívül pl. nemcsak a ket- 
tőzött többjegyű mássalhangzók automatikus elválasztását tette lehetővé, hanem olyan elválasztási 
finomságokat is, mint a kötőjelet tartalmazó szavaknál a nagyobb (három) betű távolságra történő el- 
választást (alapesetben nincs ilyen elválasztás: helyesírás-elllenőrzés, csak hellyeslíráslellenlőrlzés), 


vagy az önmagában maradó fi ligatúrák automatikus cseréjét f (keskenyebb variáns) és 1 betűkre. 


7. Mitől , fapados" kiadványszerkesztő a LibreOffice? 


Jó pár olyan alapvető funkció hiányzik belőle, ami a mai piacvezető kiadványszerkesztőkben megta- 
lálható, ilyen például a rétegek kezelése. A színkezelés vagy nyomdai vágás és jelöléseinek hiányát 
orvosolni lehet a kimeneti PDF vagy PostScript állomány utólagos feldolgozásával. Több képesség 
meglehetősen rejtve van, például a mesteroldalak megfeleltethetők a LibreOffice Writer oldalstílusa- 
inak, ahol ha azt szeretnénk, hogy keretek, képek ismétlődjenek minden ilyen stílusú oldalon, akkor 
az oldal(stílus) fejlécéhez vagy láblécéhez kell kötnünk ezeket (ettől még az oldal tetszőleges részére 
pozicionálhatók). Az oldalak hátterét a margók megőrzésével szintén kezelhetjük kerettel, de ez a ré- 
tegek hiánya miatt igencsak kényelmetlenné teszi a szövegszerkesztést a LibreOffice-ban (hacsak a 
szöveg nem keretben foglal helyet, mivel a keretek takarási sorrendje beállítható), ezért a Kiadvány- 
szerkesztés LibreOffice Writer szövegszerkesztővel jegyzet egy másik megoldást javasol, a margó 
nullára állítását, és belső margókkal való helyettesítését. 

Ami miatt mégis jó szívvel ajánlható a LibreOffice már a hagyományos kiadványszerkesztési 
funkciókra, az a fejlett és kiemelt magyar tipográfiai támogatással bíró betűtechnológia (amiben 
megelőzi a Scribust), továbbá a költséghatékonyság és a már ismerős felület. Ha kis példányszám- 
ban, digitális nyomdában készítjük el kiadványainkat, akkor a LibreOffice-ból mentett PDF-ek utó- 
lagos feldolgozására sincs szükség (esetleg nagyon nagy felbontású képek beillesztése esetén a PDF- 
exportálás beállításai között válasszuk ki a Képfelbontás csökkentése opcióban a nyomda számára 
elegendő 300 dpi-s értéket). 


8. Melyiket válasszuk? 


A következő táblázat segítséget nyújt a LibreOffice és az egyéb kiadványszerkesztésre is használt 
piacvezető, illetve piacvezető nyílt forráskódú szoftverek összehasonlításában. 

A Scribus brosúrák, magazinoldalak készítésére szánt nyílt forráskódú kiadványszerkesztő, de 
nemcsak a magyar elválasztási és egyéb sajátosságokat, vagy a nagy kiadványok szedéséhez szük- 
séges tulajdonságokat sem támogatja még, hanem a minőségi kiadványszerkesztés szempontjából 
alapvető, pl. ligatúrák, ugráló számok, valódi kiskapitálisok egyszerű használatához szükséges be- 
tűtulajdonságokat sem, ellentétben a LibreOffice-szal. Viszont a kiadványtípusok, rétegkezelés és 
nyomdai előkészítés támogatása miatt a kisebb képes kiadványok elkészítésére sokkal inkább alkal- 
mas, mint a dokumentumszerkesztők. 

Az Adobe InDesign egyike a piacvezető kiadványszerkesztőknek, számos innovatív megoldás- 
sal. Legfrissebb változatának egyik újdonsága a Hunspell szótárak támogatása, így a magyar fej- 
lesztésű, az FSF.hu Alapítvány támogatásával is fejlesztett nyílt forráskódú Hunspell helyesírás- 
ellenőrző és magyar helyesírási szótára jó szolgálatot tehet ezentúl nemcsak a LibreOffice, hanem 
az InDesign felhasználóinak is. A magyar elválasztás és tipográfia vonatkozásában viszont még el- 
marad a LibreOffice-tól. 

A Microsoft Office a piacvezető dokumentumszetkesztő, a feltörekvő LibreOffice legfőbb ve- 
télytársa. Fejlett betűtechnológia, stílusok, magyar nyelvi és tipográfiai sajátosságok kezelésében 
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elmarad a LibreOffice-tól, bár rendelkezik egy-két olyan fontos tulajdonsággal (pl. táblázatstílusok, 
függőleges tömbösítés), amivel a LibreOffice még nem. 

A TEX szövegszedő rendszer mai változatai számos olyan lehetőséget nyújtanak, amit csak a 
kereskedelmi kiadványszerkesztők, például bekezdés szintű tömbösítés, optikai margó, OpenType 
betűtulajdonságok kezelése, sőt sok olyat is, amit azok sem, különösen a matematikai szövegek 
szedésében. Jellegénél fogva (alapesetben nincs grafikus felhasználói felülete, hanem parancsállo- 
mányokkal dolgozik) még távolabb áll a klasszikus DTP rendszerektől, mint a LibreOffice, ennek 
ellenére (vagy éppen ezért) a szedési munka jól automatizálható vele (még ha ezt a összehasonlító 
táblázat nem is tükrözi). Több hiányossága van a LibreOffice-hoz képest, például a magyar elválasz- 
tás, egalizálás, alapértelmezett tipográfia, dokumentumstandard stb. esetében. 

A táblázatban a gondolatjel alapesetben hiányzó, vagy csak körülményesen elérhető képessé- 
get jelöl. Például az ОрепТуре kiskapitálisokat vagy ugráló számokat egyesével is beilleszthetjük 
a Scribusban, de ez nem hasonlítható össze azzal, hogy mindez a LibreOffice-ban valódi betűtu- 
lajdonságként is beállítható (közvetlenül, vagy karakter- és bekezdésstílusokban), ráadásul alapból 
rendelkezésre állnak az ilyen betűvariánsokat tartalmazó betűkészletek (Linux Libertine és Biolinum 
С). 

































































Képesség LibreOffice Scribus InDesign MS Office TEX 
Elsősorban DTP-re — igen igen — — 
С? igen igen igen igen — 
szabad szoftver igen igen — — igen 
ingyenes igen igen — — igen 
fejlesztő? TDF közösség Adobe Microsoft D. Knuth 
céges támogatás igen — igen igen — 
PDF-kimenett igen igen igen igen igen 
rétegek — igen igen — — 
elválasztás igen hiányos hiányos hiányos hiányos 
fattyúsorok igen — igen igen igen 
árvasorok címnélő igen — igen igen — 
soregyen igen igen igen hiányos igen 
a/az mezőkhöz” igen - - — igen 
lexikonok élőfeje — — igen igen igen 
tömbösítés szintje sor sor bekezdés sor bekezdés 
függőleges tömbösítés — — igen igen igen 
optikai margó hiányos igen igen — igen 
mikrotipográfia§ — — igen — igen 
helyesírás igen — igen igen — 








2Grafikus felhasználói felület. A TEX-hez is elérhetőek GUI, sőt WYSIWYG felületek, például ilyen а ВаКоМа ТЕХ, 
LyX és a TEXmacs, de ezekben a kiadványszerkesztőkére hasonlító közvetlen rajzolási lehetőség minimális, amit persze 
ellensúlyoz a TEX-re jellemző kiemelkedő nyomdai minőséget biztosító képletszerkesztés. 

3A The Document Foundation bejegyzés alatt álló német alapítvány, amelynek tevékenységét vezető informatikai cégek 
(Novell, Red Hat Linux, Canonical, Google), egyéb alapítványok (FSF.hu Alapítvány), illetve kormányok (Brazília) támogat- 
ják a brazil, francia, holland, német nyelvi közösségekkel összefogva. A matematikai-tudományos lapok szedésében élen járó 
TEX szerzője, D. E. Knuth lezárta a fejlesztést, már csak hibajavításokat végez, de a különböző változatok, mint a LuaTEX 
(pdfTEX) és ХеТЕХ aktív fejlesztés alatt áll. 

"Kiegészítő programokkal a TEX és a korábbi Microsoft Office változatokkal — részben PostScripten keresztül — előál- 
lítható PDF, de így ezek nem tartalmaznak olyan LibreOffice által is támogatott extra PDF-lehetőségeket, mint például a 
könyvjelzők, hiperhivatkozások, űrlapelemek. 

5Magyar elválasztás. A Scribus és a TEX hasonló elválasztási mintákat tartalmaz, de az első egyáltalán nem támogatja а 
kettőzött többjegyű mássalhangzók (ggy—>gylgy) elválasztását, a TEX pedig csak manuálisan. Az InDesign és a MS Office 
elválasztóprogramja nem választja el a többszörösen összetett szavak nagy részét, valamint a helyesírási szótárából hiányzó 
egyéb szavakat. 

$Beállítható, hogy címsorokat követő bekezdéseknél az árvasorok száma automatikusan nagyobb legyen. 

TA magyar névelők automatikus kiválasztása és frissítése numerikus mezőhivatkozások előtt. 

8A betűszélesség szemmel nem érzékelhető változtatásával. 
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Képesség LibreOffice Scribus InDesign MS Office TEX 




























































































tezaurusz igen — igen igen - 
mondatellenőrzés igen — - igen - 
EPS képek igen igen igen igen igen 
SVG képek hiányos hiányos — - — 
tartalomjegyzék igen — igen igen igen 
karakterstílusok igen — igen igen - 
bekezdésstílusok igen igen igen igen - 
táblázatstílusok — — igen igen - 
keretstílusok igen — igen - - 
GREP stílusok — — igen - - 
mesteroldalak igen igen igen - - 
alapstílusok igen — igen igen igen 
lábjegyzetek igen — igen igen igen 
csillagos lábjegyzet? igen — - - igen 
számneves mezők” igen — - - igen 
képletszerkesztés igen — igen igen igen 
betűtechnológia!! Graphite — ОрепТуре hiányos Metafont 
egalizálás 2 igen hiányos hiányos hiányos hiányos 
~ írásjelek előtt! igen — - - - 
kurzív korrekció igen — igen - igen 
optikai alávágás — — igen - - 
ligatúrák igen hiányos hiányos hiányos hiányos 
ugráló számok igen — igen hiányos igen 
igazi kiskapitális igen — igen - igen 
több betűfokozat!" igen — igen - igen 
álló kurzív zárójel igen — — - - 
ezrestagolás igen — — - - 
beépített nyelv Basic, Python Python saját VBA TEX makró 
fájlformátum! ODF saját saját OOXML saját 





9. Példa az EPS-támogatásra 


Az EPS (Encapsulated PostScript) a lapleíró PostScript nyelvet használó képformátum. Vektoros és 
bittérképes ábrákat, vektoros betűkészleteket tartalmazhatnak. A kiadványszerkesztők az EPS képek 
előnézetét mutatják szerkesztés közben, majd PostScript nyomtatásnál az eredeti EPS képet illesztik 
be a kimeneti PostScriptbe. Feladat: Készítsünk EPS képet egy PDF kiadvány valamelyik oldalából, 





9А magyar tipográfiára jellemző *, **, *** csillagozás. 

10A számokat tartalmazó mezők magyar számnévvé alakítása (a LibreOffice esetében a Graphite betűkészleteinek betűtu- 
lajdonságaként). 

11 Alapértelmezett és opcionális betűtulajdonságok kezelése. Az MS Office 2010 csak pár opcionális OpenType betűtu- 
lajdonságot kezel, pl. ligatúrákat és ugráló számokat igen, valódi kiskapitálisokat már nem. Az újabb ТЕХ rendszerek az 
OpenType betűkészletekkel, azok extra lehetőségeivel is megbirkóznak. 

12 A magyar ékezetes betűket alapból egalizálja (Linux Libertine G és Biolinum G). 

13 A magyar nyomdai hagyományok szerint a kettőspont, pontosvessző, kérdő és felkiáltójel előtt nagyobb térközt hagyunk, 
mint az angolszász tipográfia. 

MA LibreOffice következő változata a Linux Libertine Display G betűvel, és a magyar és egyéb ékezetes betűket is tá- 
mogató felső index Graphite betűtulajdonsággal három valódi betűfokozatot tartalmaz a Linux Libertine betűtípus normál 
betűváltozatából. Az Adobe szintén három, de külön megvásárolható betűfokozatokat biztosít az InDesignhoz. A ТЕХ a Me- 
taFont rendszernek köszönhetően minden betűfokozat minden betűváltozatával rendelkezik. 

I5A LibreOffice alapértelmezett formátuma a legújabb, még nem ISO, de OASIS-nak már elfogadásra benyújtott Open- 
Document 1.2., de kiválasztható az ISO OpenDocument 1.1 is. Az MS Office az elhangzott vállalások ellenére nem hogy 
alapértelmezett formátumként, de választható formátumként sem támogatja mind a mai napig az ISO Office Open XML 
Strict változatát, hanem csak az elavult átmeneti (transitional) szabványt. 
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majd ezt illesszük be egy ODF (OpenDocument), illetve PDF kiadványba képként, megőrizve az 
EPS eredeti minőségét (vektoros betűkészletek stb.). 


1. Alakítsuk a PDF kiadvány kívánt oldalát EPS állományra. Nyomtassuk PostScript fájlba a 
PDF megjelenítő programmal a PDF kiadvány megfelelő oldalát, majd a végeredményt alakít- 
suk EPS-re a GhostScript program psZepsi parancsával: 


ps2epsi kimenet.ps kimenet.eps 


2. Az EPS állományt közvetlenül beilleszthetjük a LibreOffice-ban szerkesztett kiadványunkba. 
Az OpenDocument állomány az eredeti EPS állományokat tartalmazza. Nyomtatásnál vá- 
lasszuk a PostScript fájlba nyomtatást, hogy az EPS a kimeneti állományba kerüljön. 


A рѕ2ерѕі nem túl nagy felbontású és fekete-fehér előnézetet rak az EPS állományba. A szintén 
ingyenes epstool csomaggal tetszőleges felbontású és színes előnézeteket is illeszthetünk az EPS 
állományba, így akár a nem PostScript kimenet esetén is nyomdai minőségben (igaz, bittérképes 
képként) kerülhet az EPS képek tartalma nyomtatásra, illetve PDF állományba. (PDF-et másképp 
is kaphatunk, a PostScript kimenet ps2pdf paranccsal történő átalakításával, de így a LibreOffice 
által ismert PDF-lehetőségek, például hiperhivatkozások hiányoznak, szemben a közvetlen PDF- 
exportálással.) További egyszerűsítés lehet, ha az alternatív ps2eps parancsot alkalmazzuk а рѕ2ерѕі 
helyett, mivel az ezzel kapott előnézet nélküli EPS képhez a LibreOffice készíti el az előnézetet (pl. 
a GhostScriptet használva), színesben és lényegesen jobb felbontásban, mint a ps2epsi parancs. 


10. Példa az OpenDocument használatára 


A LibreOffice egyik előnye az OpenDocument formátum, amely valódi segítséget nyújt az olyan 
összetett kiadványok elkészítésénél is, mint a korábban említett Biblia. Sőt, ilyen méretű és jellegű 
kiadványok szedésére már nem is nagyon javasolható más módszer, mint az automatikus szöveg- 
szedés. Az eredetileg HTML formátumban lévő Károlyi-biblia (Magyar Elektronikus Könyvtár) az 
ODFpy (OpenDocument Python programkönyvtár) alkalmazással lett OpenDocument formátumúra 
alakítva. Az OpenDocument állományt pedig a LibreOffice szedte ki, majd került elmentésre PDF- 
formátumban, a PDF-nézegetőkben is működő kereszthivatkozásokkal. 


10.1. ODFpy 


Az ODFpy az OpenDocument állományok előállítására és módosítására szogáló Python könyvtár. 
Eredeti fejlesztője Michael Howitz, a rendszeresen frissített programkönyvtár karbantartója Søren 
Roug, az EU Európai Környezetvédelmi Ügynökségének munkatársa. A programkönyvtár tulajdon- 
képpen egy burok az OASIS/ISO OpenDocument szabvány körül: lehetővé teszi, hogy pár utasí- 
tással helyes ODF állományokat állítsunk elő, illetve módosítsunk, miközben nem kell tartanunk 
attól, hogy hibás elemeket vagy attribútumokat helyezünk el az XML-ben. Használatához érdemes 
az OpenDocument szabványt is kéznél tartani (ami egyben maga is jó példa az OpenDocument hasz- 
nálatára), 1. http://www.oasis-open.org/standards. 


10.2. Példa ODF állomány létrehozására 


A következő kis Python program egy , Szia, Világ!” sort tartalmazó OpenDocument szöveges (ODT) 
állományt hoz létre helloworld néven: 
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10.3 Betűkészletek beállítása 








# -»- Encoding: UTF-8 —x- 
from odf.opendocument import OpenDocumentText 
from odf.text import Р 





textdoc = OpenDocumentText () 

р = P(text = u"Szia, Világ!") 
textdoc.text.addElement (р) 
textdoc.save("helloworld", True) 





10.3. Betűkészletek beállítása 


A betűkészleteket és az opcionálisan használt Graphite betűtulajdonságokat előre deklarálnunk kell: 


from odt.style import FontFace 

def set_font (fname): 
textdoc.fontfacedecls.addElement ( (FontFace (name=fname, 

fontfamily=fname, fontfamilygeneric="roman", fontpitch-"variable"))) 

set_font ("Linux Libertine G") 

set_font ("Linux Libertine G:sups=1&pnum=1") 

















10.4. Címsor beállítása 


Illesszünk be egy Címsor 1 stílusú címsort, amit a megfelelő bekezdés- (középre igazítás) és karak- 


terformázással (a korábban beállított betűk valamelyike félkövér betűváltozatban, piros színben, 16 
pontos betűméretben) láttunk el: 


from odf.style import Style, FontFace, TextProperties, ParagraphProperties 
Һ1 = Style (name="Heading 1", family-"paragraph") 

h1.addElement (ParagraphProperties (textalign="center")) 

h1.addElement (TextProperties (fontsize="16pt", 

fontweight-"bold", color="#FF0000", fontname="Linux Libertine G")) 
textdoc.styles.addElement (h1) 

textdoc.text.addElement (H (outlinelevel=1, text=u"Főcím", stylename-h1)) 























10.5. Szövegkeretek beillesztése 


A következőben a margóra helyezünk egy olyan szövegkeretet, ami egy szintben van a horgonypont 
bekezdésen belüli karakterpozíciójával. А beállításokhoz egy új keretstílust hozunk létre „Е” néven. 
A szövegkeret tartalma egyszerűen , szöveg". 

A keretelemen belül egy szövegdoboz elem található. Ezek méretét minimálisra vettük, hogy szé- 
lességük a szövegtartalomnak megfelelően változzon. Ezen a módon elérhető, hogy tükrözött oldalak 
esetén is a margón elhelyezett szöveg fix távolságra legyen a bekezdések szövegétől (a páros-páratlan 
oldalaktól függő balra, vagy jobbra igazítás csak program útján állítható be, az ODF-ben nem, ezért 
ezt a keret változó méretével helyettesítjük, ami egysornyi margóra helyezett szöveg esetén ugyanazt 
eredményezi). A LibreOffice hatékonyságát jól jelzi, hogy képes a Biblia 30 ezer kereszthivatkozását 
tartalmazó 13 ezer szövegkeretet megjeleníteni, és az eredményt PDF-formátumban elmenteni. (Ér- 
dekességképpen, az InDesign felhasználói kézikönyve figyelmeztet arra, hogy ne használjunk sok 
szövegkeretet.) 


from odf.style import GraphicProperties 
from odf.draw import Frame, TextBox 
Fstyle = Style (name="F", family="graphic", parentstylename-"Standard") 
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Fstyle.addElement (GraphicProperties (horizontalrel-"page-end-margin", 
horizontalpos="from-inside", x="0.3cm", 

verticalrel="char", verticalpos="top")) 
textdoc.styles.addElement (Fstyle) 

p= Р (у) 

f = Frame (name="keret", stylename=Fstyle, anchortype="char", 
x="0.3cm", zindex="0") 

p.addElement (f) 

tb = TextBox (cornerradius="1mm", minwidth="0.2in", minheight="0.3cm") 
f.addElement (tb) 

tbp = P (stylename="Margin", text=u"szöveg") 

tb.addElement (tbp) 

















10.6. További példák 


Dokumentált példa a Biblia kiszedésére: http://www.numbertext.org/biblia 
ODFpy honlap: http://odfpy.forge.osor.eu/ 


11. Hogyan tovább? 


Ahogy az összefoglaló táblázatból kiderül, a LibreOffice már most számos egyedülálló DTP képes- 
séggel rendelkezik, és nemcsak a magyar tipográfia vonatkozásában. A párizsi LibreOffice konferen- 
cián nemrégiben elhangzott előadás!" összefoglalta a fő fejlesztési feladatokat, és sikerült a szakma!" 
és a LibreOffice fejlesztők figyelmét is felkelteni, felmerült például a Microsoft Publisher import- 
szűrő elkészítésének gondolata. Viszonylag egyszerűen kivitelezhető megoldási javaslat készült az 
OpenType betűtulajdonságok és a rétegek kezelésére, vagy ami a LibreOffice-ra nézve szinte köte- 
lező fejlesztésnek számít, az OpenDocument szabvány számos olyan, a LibreOffice által még nem, 
vagy kevésbé támogatott funkciót tartalmaz (pl. táblázatstílusok, lekerekített szegélyű szövegdobo- 
zok), amelyek várható megvalósításával a LibreOffice továbbhaladhat a megkezdett úton, nemcsak 
egy szabad és nagy tudású, hanem versenyképes kiadványszerkesztőt nyújtva mindenkinek. 


12. Hivatkozások 


Jegyzet: http://www.numbertext.org/libreoffice 
LibreOffice Graphite betűkészletek: http://www.numbertext.org/linux/index hu.html 
LibreOffice híroldal: http://www.libreoffice.hu 





. http://libreoffice.hu. towards-desktop-publishing-%E2%80%93-angolul-es-magyaru 
16L, http://libreoffice.hu/201 1/10/17/ ds-desktop-publishing-%E2%80%93-angolul gyarul/ 
17 http://libregraphicsworld.org/blog/entry/libreoffice-is-diving-into-desktop-publishing 
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Zorp, a pokoli operátor tűzfala 


Pfeiffer Szilárd 


Kivonat 


Az előadás célja a Zorp protokollelemezési és -módosítási képességében rejlő számos lehető- 
ség közül néhány olyan felvillantása, amelyek a mindennapi rendszergazdai gyakorlatban előfor- 
duló problémákra adnak megoldásokat. 

Ilyenek lehetnek a vírusszűrés különböző (HTTP, SMTP) protokollokban, protokollelemek 
szűrése, módosítása, tiltása (pl: referer host, user-agent headerek értékének cseréje HTTP forga- 
lom, csak read-only parancsok engedélyezése FTP protokoll esetén), SSL titkosítás kibontása, 
szerver audit lehetőségek. 
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1 MIAZ A ZORP? 





1. Mi az a Zorp? 


Tömören fogalmazva a Zorp egy nyílt forrású mély protokollelemző proxy tűzfal, ami roppant tu- 
dományosan hangzik, vagyis akár a pokoli operátor kifogásnaptárában is szerepelhetne, de a benne 
rejlő lehetőségeket látva inkább a feltétlenül használandó szoftverek listájára kerülne fel. Lássuk mi- 
ért! Először is az imént említett mágikus kifejezés kulcsszavait sorra véve próbáljuk meg bizonyítani 
miért! 


1.1.  Protokollelemzés 


Funkciójukból fakadóan a tűzfalalkalmazások mindegyike képes a hálózati forgalom bizonyos mérvű 
elemzésére, lévén ennek hiányában nem tudnánk a forgalom szabályozására vonatkozó feltételeket 
megadni. Ez a Zorp esetén sincs másképp. A különbség az egyes szoftverek között az elemzés mély- 
ségében mutatkozik meg. Míg például a Netfilter esetén az oly sokat emlegetett ISO/OSI modell 
negyedik — azaz szállítási — rétegén túli elemeket nemigen használhatjuk fel a hálózati forgalom sza- 
bályozásánál, addig a Zorp esetén akár a legfelső — azaz az alkalmazási — réteget górcső alá véve is 
hozhatunk döntéseket. A döntés vonatkozhat a szolgáltatás egészére, vagyis tilthatjuk, vagy engedé- 
lyezhetjük például egy FTP szerver teljes elérését a felhasználók egy csoportja számára, de lehet szó 
arról is, hogy letölteni engedünk, feltölteni viszont már nem, és az előbbit is csak akkor, hogy ha a 
letöltendők vírusmentesnek bizonyultak. 


1.2. Proxy tűzfal 


Csaknem minden, ami ezen kifejezésről eszünkbe juthat, igaz a Zorp kapcsán is. Elsőként minden- 
képpen a proxy szerverek azon sajátossága, hogy beékelődnek a kliens és a szerver közé, elszeparálva 
ezáltal a hálózati kommunikáció két szereplőjét egymástól, és minden egyes kérést, illetve választ 
újrafogalmaznak a két szereplő között. A Zorp ebben a tekintetben annyival több versenytársainál, 
hogy mindezt alkalmazásszinten tudja megtenni, a felhasználás különböző módjai (forward proxy, 
reverse proxy) mellett. Ehhez szükségesek a C nyelven implementált, viszont Python nyelven konfi- 
gurálható, bővíthető protokollelemző osztályok (a Zorp terminológiájában proxy), melyekből a nyílt 
forrású változat esetén kilenc, míg a kereskedelmi verzióban huszonöt áll rendelkezésre. 


1.3. Moduláris szerkezet 


A Zorp kétségkívül legnagyobb előnye a testreszabhatóság, amely a szoftver szerkezetének modulá- 
ris felépítése nélkül nem volna lehetséges. A mindennapi használat során ez annyit jelent, hogy ha 
nincs szükségünk egy adott proxy kapcsán speciális működésre, akkor gyakorlatilag szinte semmit 
nem kell tennünk azért, hogy élvezhessük a hálózati protokoll applikációs szintig történő elemzését. 
Ha viszont ennél többre van igényünk, kontrollálni kívánjuk az adott forgalmat, akkor is csak arra 
kell összpontosítanunk, amit konkrétan elérni szeretnénk (pl: egy HTTP header módosítása), minden 
egyebet készen kapunk. Ezeken túl viszont arra is van lehetőség, hogy a Zorp csak a hálózati kap- 
csolatot kezelje, és a protokoll teljes elemzését magunk végezzük függetlenül a gyárilag meglévő 
proxyktól. 

A szállítási rétegben megvalósított biztonsági protokollok (SSL/TLS) implementációja egy ön- 
álló alrendszert, ha úgy tetszik modult képez, így az ezekhez kapcsolódó beállítások a konkrét app- 
likációs protokolltól függetlenül tehetőek meg, ami lehetőséget biztosít arra is, hogy egy általunk 
implementált protokollértelmező SSL kapcsolaton belül és kívül egyaránt működhessen. A Zorp al- 
kalmas külső eszközökhöz, modulokhoz való integrációra is, melynek lévén viszonylag könnyen 


мд 


valósíthatóak meg spam-, illetve vírusszűrő megoldások. 
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1.4 Nyílt forrás 





1.4. Nyílt forrás 


Lévén egy szabad szoftveres konferencia előadásának kiegészítő anyagáról van szó, nagy megle- 
petést nem okozhat, hogy a Zorp nyílt forrású termék, ugyanakkor néhány kérdést mégis fontos 
tisztázni, ha más nem, a licenchuszárok kedvéért. Egyrészről, hogy a szerzői jogi védelem pontosan 
milyen formájáról van szó, másrészről, hogy kizárólagos-e ez a licencelés. Az első kérdésre kettős 
válasz adható, lévén maga a Zorp is két összetevőre oszlik, magára a tűzfal applikációra, illetve egy 
hozzá kapcsolódó függvénykönyvtárra. Mindkettő az FSF által kiadott licenc — az előbbi (Zorp) 
GPL, míg az utóbbi (Libzorp11) LGPL -hatálya alatt érhető el. A második kérdésre adott válasz 
egy kifejezésben foglalható össze; dual-license, vagyis létezik egy nyílt forrású (Zorp/Zorp GPL), 
illetve egy kereskedelmi (Zorp Professional) változat, a megfelelő licencelési, illetve számos techni- 
kai különbséggel, melyekről később még esik szó. 


2. Mire jóa Zorp? 


Ha egy marketing anyag sorai közé tévedt volna a nyájas olvasó, a fent megfogalmazott költő kér- 
désre a válasz bizonnyal az lenne; mindenre. Így viszont némi szerénységet felmutatva szűkítjük 
ezt a halmazt belátva, hogy a Zorp közel sem mindennek a teteje, viszont minden funkcióban segít- 
ségünkre lehet, ami a mély protokollelemző proxy tűzfal varázsos meghatározás alapján elvárható. 
Lássuk mik lennének ezek. 


21.  Hozzáférés-vezérlés 


A proxyszerverek ezen alapvető funkciója esetén a Zorp annyiban különleges, hogy itt is el tud sza- 
kadni az alacsonyabb ISO/OSI rétegektől. Míg más eszközöknél csak a hálózati réteg attribútumai 
— IP címek, illetve alhálózatok — segítségével szabályozhatjuk a szolgáltatásokhoz való hozzáférést, 
addig a Zorp egy saját rendező mechanizmusa alapján. Ez a zóna, ami alhálózatok szabadon csopor- 
tosítható halmazát jelenti, melyek fába szervezhetőek. A zónastruktúra szintje között a szolgáltatások 
elérésének szabályai öröklődnek, de kivételek is megadhatóak, így egy IP alhálózatoktól független 
adminisztratív hierarchia hozható lére, ami nem a hálózati eszközeink elrendezését, hanem a hozzá- 
férés szab @?lyait tükrözi. 

A kik mellett a hozzáférés-vezérlési rendszer megalkotásakor a mit és a hogyan kérdéseire is vá- 
laszt kell adnunk, vagyis nem csak az határozandó meg, hogy kik számára érhetőek el az erőforrások, 
hanem azt is, hogy milyen feltételek mellett. Lehet szó egész egyszerűen csak arról, hogy egy szer- 
ver elérése esetén minden egyes végrehajtott műveletről bejegyzés készül a rendszernaplóba. Vagy 
tilthatjuk például a szerver, illetve a kliens olyan funkcióit, melyek inkompatibilitást okoznak. Szűr- 
hetjük a protokoll némely elemeit, módosíthatjuk azok értékeit, hogy elkerüljük érzékeny adatok 
kiszivárgását. Ellenőrizhetjük az adattartalom vírusmentes mivoltát. Kibonthatjuk, majd visszacso- 
magolhatjuk a forgalmat védő titkosítást. Ebből adnak ízelítőt a következő fejezetek. 


2.2.  Adatszivárgás megelőzése 


Számos protokoll esetén léteznek olyan — egyébiránt teljesen szabályos, következésképp a tűzfalak 
által alapvetően nem szűrt vagy tiltott — protokollelemek, melyek a kliensen futó szoftverekről, eset- 
leg annak hálózati beállításairól szivárogtatnak ki adott körülmények között érzékeny információkat. 
Erre példa a user-agent mező – egyebek mellett — a HTTP protokoll fejlécében, ahol is ennek 
értéke a használt böngésző típusa, illetve verziója, mely akaratunkon kívül jut el az általunk éppen 
meglátogatott webszerverhez. 
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2 MIREJÓ A ZORP? 





Ehhez közel azonos módon szolgáltathatja ki a böngésző a proxybeállításokat, gépünk IP címét, 
vagy épp az előzőleg látogatott oldal (amiről az adott szerverre jutottunk) URL-jét. Ehhez hasonló 
megoldások azonban nem csak a HTTP protokollban szerepelnek, hanem másutt is, melyekről ér- 
demes tudni és adott esetben érdemes őket tiltani. Erre a Zorp könnyen használható és rugalmas 
megoldást ad. 


2.3.  Interoperabilitás 


A fenti példánál maradva a böngésző típusának nem csak az elrejtése lehetséges, de a , meghamisí- 
tása" is, ami az interoperabilitás megteremtéséhez annyiban segít minket hozzá, amennyiben talál- 
kozunk azzal az — egyébiránt egyre ritkábban előforduló — esettel, amikor is egy webszerver annak 
ellenére is kikötést tesz a böngésző típusára, hogy erre érdemben alátámasztható oka nincs. Az ilyen 


helyzet könnyedén feloldható azáltal, hogy a böngésző által küldött user-agent mező értékét úgy 
változtatjuk meg, hogy az a webkiszolgáló számára elfogadható legyen. 


Éppúgy kellemetlenségeket okozhat bizonyos — általában nem mai keletű — szoftvereknél a tit- 
kosított forgalom kezelésének hiánya, főként ha egy nem megbízható hálózaton keresztük kell át- 
juttatnunk az adatokat. Erre a helyzetre természetesen számos megoldás létezik, ugyanakkor ha a 
problémát megfejeljük azzal, hogy a forgalmat egy tűzfalon is szeretnénk keresztül vezetni, akkor 
válik igazán hasznossá a Zorp azon szolgáltatása, mely alkalmassá teszi a kliens és a szerver irá- 
nyába más titkosítási metódus (TLS, SSL) használatára. Ennek szélsőséges este, amikor a Zorp csak 
az egyik – megbízhatatlannak tartott — irányba végez titkosítást, míg a másik — megbízhatónak vélt — 
irányba nem. 


Fentiekhez nem feltétlenül elegendő csupán a titkosított csatornák kiépítésének, valamint újra- 
építésének képessége, lévén a protokoll részeként is kezdeményezhető titkosított kapcsolat kiépítése, 
ami az interoperabilitás egy újabb területére, a funkciók elrejtésére vezet át minket. Amennyiben azt 
szeretnénk, hogy bizonyos — mind a kliens mind a szerver által ismert — funkciók ne legyenek el- 
érhetőek — mondjuk valamilyen inkompatibilitási probléma miatt —, ezt is módunkban áll a Zorp 
segítségével megtenni. 

A titkosítási példát tovább gördítve adott a lehetőség, hogy az SMTP protokoll feature listájából, 
kiemeljük a STARTTLS elemet, ami megakadályozza, hogy a kliens és a szerver ilyen módon kom- 
munikáljanak egymással. Az SSL beállítások egyes kombinációinál — például ha a szerver irányába 
kötelező az SSL — azt a Zorp automatikusan megteszi. 


2.4. Tartalomszűrés 


Nincsen tűzfal tartalomszűrés nélkül. A szabály alól a Zorp sem kivétel, még akkor sem, ha a Zorp 
önmagában csak korlátozottan alkalmas ezen feladat ellátására. A hangsúly az önmagában kifejezé- 
sen van, hiszen kiegészítve egyéb eszközökkel, mint vírus-, spam-, URL-szűrő, a Zorp, mint suszter, 
maradhat a kaptafánál, vagyis nem tesz egyebet, mint értelmezi az adott protokollt, ennek segítségé- 
vel kiemeli a hálózati forgalomból azt a részt (URL, letöltendő fájl, levél, . . . ), melyet továbbadva a 
alkalmas szoftvernek, annak visszajelzése alapján döntést hozhat, hogy visszautasítja, átengedi, ka- 
ranténba helyezi, vagy csak naplózza az eseményt függően akár más beállításoktól, vagy a forgalom 
egyéb körülményeitől. Ehhez nem kell egyebet tennünk, mint egy illesztőprogramot helyezni tűzfa- 
lunk és az általunk választott tartalomszűrést biztosító eszköz közé, mely tudatja előbbivel az utóbbi 
által megállapítottak alapján hozott döntést. 
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2.5 Audit 





2.5. Audit 


Egy hálózat adminisztrációja során az erőforrások elérését szabályozó rendszer felállítása csupán az 
első lépés, ennek a rendszernek a felügyelete adja a munka nagyobb részét, melyből a szabályok 
fejlesztése, átalakítása következik majd. Mindenekelőtt azt kell megtudnunk, mi az ami a hálóza- 
tunkban aktuálisan zajlik. Egyrészről mik azok az események, amik a megalkotott szabályrendszer 
áthágására irányultak. Másrészről az engedélyezett akciók közül melyek következtek be és milyen 
formában. A Zorp mindkét típushoz tartozó eseményekről bejegyzéseket ír a rendszernaplóba. 

Az utóbbi eset az, ahol az applikációs szintű protokollelemzésnek hasznát láthatjuk, hiszen az 
egyes protokollok parancsainak szintjén van módunk rálátást szerezni a hálózatban zajló esemé- 
nyekre, illetve rögzíteni azokat a rendszernaplóba. Ennek mind belső, mind külső audit során ko- 
moly hasznát vehetjük, hiszen — a naplózás megfelelő beállításai mellett — igazolható, hogy mely 
események történtek meg és melyek nem egy adott időszakban. Emellett természetesen forgalmi-, 
illetve eseménystatisztikák alapjául szolgálhatnak ezek a naplóbejegyzések. 


2.6. Flexibilitás 
Az eddig leírtak kész, vagy legalábbis félkész megoldásként a Zorp részét képezik, ugyanakkor a 


Zorp erejét épp az adja, hogy szabadon és rugalmasan bővíthető saját céljaink szerint. Ehhez a Zorp 
azon sajátosságát használhatjuk ki, hogy a már meglévő eszközöket (proxyk) könnyen újrahasznosít- 
hatjuk, vagyis az egyes protokollelemzőket nem kell újra megírnunk, elegendő azok Python nyelvű 
változatait újra felhasználva csak a szükséges kiegészítéseket megtenni. Még abban az esetben is 
igaz ez, ha teljes egészében magunk kívánjuk a hálózati forgalmat feldolgozni — amit egyébiránt 
megtehetünk úgy is, hogy hozzá megírjuk a alkalmas C nyelvű proxyt —, mivel létezik egy erre a 
célra szolgáló Python osztály (AnyPy). Minden, ami az OSI modell alsóbb rétegeiben zajlik, imple- 
mentált a proxyban, nekünk csak az ezen felüli — leginkább az alkalmazási — réteg részleteire kell 
koncentrálnunk. 

Ami elmondható, hogy a már meglévő eszközökből való öröklés és a nyílt forrás adta előnyök 
révén számos igény kielégíthető. 


3. Hogyan működik a Zorp? 


Ennek az anyagnak a keretei nem teszik lehetővé az egyes konfigurációk részletes ismertetését. A 
működés részleteinek tekintetében érdemes a Zorp GitHub! oldalát meglátogatni, ahol számos konfi- 
gurációs példa? érhető el. Ezen felül virtuális gépek? révén egy teljes működő rendszerhez juthatunk, 
ahol a valós működés tesztelhető. 





!http://github.com/balabit/zorp 
2https://github.com/balabit/zorp-examples 
3http://people.balabit.hu/szilard/zorp-gpl/virtual-machines/ 
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Nyílt forráskódú megoldások a közigazgatásban 


Szegfű László 


Kivonat 


A magyar költségvetés számára rendkívül nagy teher a közszolgálati intézmények éves szoftverli- 
cenc ellátása, legyen szó a közigazgatás vagy akár a közoktatás számára vásárolt termékek áráról. 
A közigazgatásban az informatikával támogatható feladatok jellemzően nem specializáltak, így 
lehetővé válik olyan megoldások használata, amelyek olcsóbban vagy akár ingyenesen is besze- 
rezhetők. A közigazgatási informatikában használt programok nyílt forráskódú rendszerekre tör- 
ténő cseréjével jelentős költségmegtakarítás érhető el. Szeged M. J. Város példája mutatja, hogy 
csak a polgármesteri hivatalban használt szoftverek ilyen cseréjével 8 év alatt több száz millió 
forint értékű licenc díjat lehet megtakarítani. A cserék természetesen valamennyi lemondással 
járnak, de a teljes közigazgatás átalakításával a főként kompatibilitási problémák jelentős része 
kiküszöbölhető. 
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2 NYÍLT FORRÁSKÓDÚ RENDSZEREK BEVEZETÉSÉNEK CÉLSZERŰSÉGE 





1. Bevezetés 


A magyar közigazgatásban elterjedt szoftvertermékek vásárlása, fenntartása rendkívüli terhet ró a 
mindenkori költségvetésre. Többször felmerült a kérdés, hogyan lehetne költséghatékony megoldá- 
sokat találni a kiadások mérséklésére. Ez a kérdés nem csupán olyankor kell, hogy felmerüljön, 
amikor gazdasági válság van, a gondos gazda szerepét az államnak, a közigazgatási szerveknek és 
a költségvetési intézményeknek mindenkor felelősséggel el kell látnia. Szeged Megyei Jogú Vá- 
ros Önkormányzata több, mint 8 éves tapasztalata alapján megmutatható, hogy gondos előkészítést 
követően létrehozható jól működő, olcsó infrastruktúra, elsősorban nyílt forráskódú megoldások al- 
kalmazásával. 


1.1. Közigazgatási szoftverek 


A közigazgatási szerveknél a legtöbb hivatalban végfelhasználói szempontból jellemzően kevés 
szoftverre van szükség, így például: operációs rendszerre, irodai alkalmazáscsomagra, irodai háttér- 
támogatást nyújtó rendszerekre (ezek lehetnek kisebb szigetszerű célszoftverek, de lehetnek akár na- 
gyobb adatbázisrendszerek is), elektronikus levelezési rendszerekre és internetböngésző szoftverre. 
Ezen kívül kevés számban előfordulhatnak speciális célszoftverek, tervezőrendszerek, csoportmunka- 
támogató szoftverek, grafikus vagy egyéb programok. 

Az irodai háttértámogatást nyújtó szigetalkalmazásokat, vagy nagyobb adatbázisrendszereket 
vizsgálva megállapíthatjuk, hogy ahány hivatal, ahány ügye, annyi megoldás létezik. Ezek a szoftve- 
rek többségükben a papír alapú megoldás mellett működnek, ennek legfőbb oka, hogy a munkafo- 
lyamat kapcsán keletkező aláírásokat nehezen lehet hiteles formában — mindenki megelégedésére — 
elektronikusan kiváltani. Ezek a programok általában rendkívül drágák, és az adatok kinyerése, fel- 
dolgozása, más rendszerekbe történő átemelése rendkívül körülményes. 

Az informatika működéséhez szükségszerűen a szerveroldali megoldások is hozzátartoznak. Itt 
jellemzően ugyanazok a feladatok adódnak, mint minden más esetben: többek között a fájlok táro- 
lása, adatbázisok üzemeltetése, levelezés, internetes portál működtetése, adatbiztonság kialakítása 
stb. 


2. Nyílt forráskódú rendszerek bevezetésének célszerűsége 


2.1.  Költséghatékonyság 


A nyílt forráskódú rendszerek bevezetése mellett és ellen egyaránt számos érv sorolható fel. A mel- 
lette szólók közül a legfőbb érv minden esetben a költséghatékonyság. Általában mindenki olyan 
termékeket vásárol, ami az ő igényeinek megfelelően a legjobb ár/érték arányú. Akinek több pénze 
van, jobb, kényelmesebb, többet tudó terméket tud vásárolni, akinek kevesebb forrása van, értelem- 
szerűen neki megfelelőt keres. Nem szabad elfelejteni azonban, hogy a közigazgatás az adófizetők 
pénzéből gazdálkodik, így elvárható, hogy mindenkor az igényeinek megfelelő legolcsóbb — adott 
esetben ingyenes — terméket és így szoftvert szerezze be. Tehát amennyiben létezik ingyenes alterna- 
tíva, a közigazgatási szereplők a gondos gazda szerepével élve kötelesek azt beszerezni. 


2.2. Függetlenség a szállítótól 


A magas költségek nem csak az általános szoftverek árában követhetők nyomon, az irodai folya- 
matok informatikai támogatására készített egyedi programok ára és fenntartása is rendkívül drága. 
A költségeket általában az határozza meg, hogy a piacon régóta jelen lévő beszállítók a kezdeti 
időkben — néhány kivételtől eltekintve — indokolatlanul magas fejlesztési és licencdíjakat állapítottak 
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ЖШ 


meg. Ezt megelőzően általában ingyenesen felajánlották a szoftvereket használatra, majd amikor а 
felhasználók megszokták a felületet, és kellő mennyiségű adatot vittek be a rendszerbe, a fejlesz- 
tők bejelentették a további felhasználás feltételeit, mintegy kész tények elé állítva a hivatalokat. A 
jogszabály-módosítások vagy a felhasználói igények változása okán szükségszerű drága fenntartási 
költséget fizetni a fejlesztőknek. A már meglévő szoftverek módosításának vagy fejlesztésének a 
költsége pedig gyakorlatilag annyiba kerül, amennyit a fejlesztő ezért a munkáért elkér. A fejlesz- 
téseket ezután— lévén a vagyoni jogokat nem ruházza át— bármely másik, hasonló munkát végző 
közigazgatási szervnek is el tudja adni, anélkül, hogy újabb munkaórákat fektetne a fejlesztésbe. Az 
így elvégzett munka nem csak indokolatlanul magas költséggel jár, de többszörösen kifizetésre ke- 
rül az adófizetők pénzéből. Külön kockázatot jelent az időközben jogutódlás nélkül megszűnő, vagy 
érdektelensége okán a munkát egészen egyszerűen megtagadó vállalkozó. 


A fent felsorolt programok általában erősen platformfüggők, így az esetleges olcsóbb, vagy ma 
már nagyon népszerű, de nem szokványos felületeken nem futtathatók. Ennek az az eredménye, hogy 
a többletköltségeken felül a technológiai fejlődést is erősen hátráltatják. A "rátermettebb" fejlesztők 
megpróbálják ugyan átültetni az elavult technológiát valamilyen grafikus felületre, de ezzel sajnos a 
platformfüggőség nem szűnik meg, csak más felülethez köti a felhasználót. 


Köztudott, hogy minden rendszert egyszer ki kell cserélni, mert elavul. Ezért a jövőben olyan 
rendszer(ek) fejlesztésére kell törekedni, amelyek forráskódja és vagyoni joga "birtokon belül" ma- 
rad. Ezek a megoldások lehetnek akár publikált nyílt forráskódú, akár az állam (vagy az adott köz- 
igazgatási szerv) tulajdonába kerülő forráskódú és vagyoni jogú szoftverek. Ilyen megoldások hasz- 
nálata esetén a fejlesztő a ténylegesen elvégzett munkájáért kapja meg a megfelelő díjazást, és mó- 
dosítási vagy fejlesztési igény esetén az adott közigazgatási szerv eldöntheti, hogy a munkát maga 
végzi el, vagy az adott fejlesztőt bízza meg, vagy megversenyezteti az árakat más fejlesztőkkel is. 
Értelemszerűen egy nagyobb munka esetén nehéz olcsóbb árat ajánlani az eredeti fejlesztő áránál, 
de megakadályozható az indokolatlanul magas, és többször beszedett munkaköltség. A verseny tu- 
data önmagában árletörő hatású. Ha nem sikerül olcsó megoldást találni, a forráskód birtokában a 
rendszerek akár ki is válthatók. 


2.3.  Interoperabilitás 


A növekvő információigénnyel arányosan egyre nagyobb az igény a meglévő adatbázisrendszerek 
átjárhatóságára, összekapcsolására a gyorsabb és pontosabb, valamint a lehető legszélesebb körű 
adatszolgáltatásra, illetve az adatok minél kevesebb munkával és minél kevesebb adatbázisban tör- 
ténő tárolására. 

A zárt kódú rendszerek használatának interoperabilitási szempontból több kockázata is felmerül. 
Két rendszer illesztése mindkét rendszer fejlesztőjének, és a megrendelőnek egyidejű egyetértésén 
és munkáján alapul. Ezt összehangolni rendkívül nehéz, és ennek a megvalósulása és költsége meg- 
lehetősen bizonytalan. Felmerülő probléma esetén a fejlesztők "egymásra mutogatnak". 


Nagyobb a probléma azonban, ha nem csak két rendszert kell összekapcsolni. Ha egy központi 
rendszerhez több, egymástól eltérő szoftvert használó hivatal alkalmazott megoldását kell hozzáil- 
leszteni, ezek a problémák — és ezzel egyidejűleg a hibalehetőségek is — hatványozottan jelentkezhet- 
nek. 

A forráskód(ok) birtokában az átjárhatóság megoldása is könnyebb, mivel megismerhetjük a 
fogadó rendszer működését, ehhez alakíthatjuk a saját rendszerünket. Mindkét oldalon kevesebb 


együttműködés szükséges a hatékony munkához, a kód birtokában egyszerűbben visszafejthetők a 
hibák is. 
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2.4.  Integrálás, migrálás 


Ahogy korábban szó volt róla, felelősen gondolkodó informatikus tudja, hogy minden rendszert 
egyszer ki kell váltani. Az adatok kinyerhetőségét ezért minden újonnan fejlesztett rendszernél biz- 
tosítani kell. Ehhez szükség van a kiváltandó rendszer fejlesztőjére, hiszen zárt kódú megoldásoknál 
nem ismerjük az adatmodellt, az adatbázis-szerkezetet és a számolt adatokat, illetve azok összefüg- 
géseit és a többit. 

A zárt rendszerek esetében általában a kiváltandó rendszerek fejlesztője egyáltalán nem érdekelt 
a rendszer kiváltásában, így jellemzően az ilyen munkálatokért olyan költségek kerülnek felszámo- 
lásra, amelyek kifizetése elbizonytalanítja vagy ellehetetleníti a szoftver kiváltását. A tapasztalatok 
szerint többéves fenntartási és licenc költség megtérülését biztosan bele kell számítani az ilyen mun- 
kálatok árába. Külön gondot okoz, ha az időközben megszűnt vagy ellehetetlenült vállalkozásokat 
nem lehet felderíteni vagy rávenni a migrálásban történő segédkezésre. 

Adathibák, konverziós hibák, nem konzisztens adatok, és a többi hiba esetén azok javítása is szin- 
tén "egymásra mutogatást" eredményezhet a régi és az új rendszer fejlesztője illetve a megrendelő 
között. 


2.5. Átlátható kód 


A zárt kódú programok esetében a program tényleges működése nem ismerhető meg. A felhasználó 
"fekete dobozként" látja a szoftvert, nem tudja, hogy az általa bevitt és kinyert adatokon felül még 
milyen adatok kerülnek bele, és milyen adatok kerülnek ki a programból. 

Sokan félnek a nyílt forráskódú megoldásoktól, mert azt gondolhatják, hogy így megismerhetők 
és ezáltal manipulálhatók a bevitt, és kinyerhetők a szenzitív adatok. Pedig éppen a zárt rendszerek- 
nél nem tudjuk, hogy ez megtörténik-e. 

A forráskód birtokában a rendszer működése ellenőrizhető. Nem kell feltétlenül arra gondolni, 
hogy a közigazgatás bármelyik szereplője kész és képes egy nagyobb program forráskódjának ellen- 
őrzésére, de egy szoftver minőségbiztosítása független szakértőkkel is elvégeztethető. Egy "kész" 
nyílt forráskódú szoftvert pedig olyan közösség fejleszt, akiknek egészen biztosan feltűnik, ha va- 
laki direkt vagy véletlenül "ártalmas" kódrészletet akar a rendszerbe csempészni. A közösségi fej- 
lesztések esetén a hibák felfedezése is nagyobb valószínűséggel megtörténik, hiszen a fejlesztők nem 
egyféle elgondolás alapján dolgoznak. 


2.6.  Egyenértékűség 


Az elmúlt néhány évben a közösségek által fejlesztett, általános felhasználású szoftverek rendkívül 
sokat fejlődtek. A közigazgatásban használt, korábban felsorolt szoftvertermékek nagy többségének 
általában van egy vagy akár több, ilyen megbízható alternatívája. Ahogy operációs rendszer, irodai 
alkalmazáscsomag, levelező vagy internetböngésző program, úgy akár komoly fotó- és hangszer- 
kesztő vagy tervező rendszer is létezik, megfelelő minőségben. 

Az ilyen nyílt forráskódú programok használata általában ingyenes, míg ezek zárt kódú alter- 
natívái jellemzően nagyon sokba kerülnek. Ez az oka, hogy ezek sokszor legfeljebb egy-két számí- 
tógépre kerülnek jogszerűen telepítésre, pedig elképzelhető, hogy az érdemi munkavégzéshez ettől 
több licencre lenne szükség. Ha minden közigazgatási szereplő minden munkájához az ingyenes 
szoftvereket használná, biztosítható lenne az adatátjárhatóság. Nem lenne szükség nagyon drága cél- 
szoftvereket vásárolni csak azért, hogy egymás adatait olvasni tudják. Sok esetben egyébként a nyílt 
forráskódú program szabvány formátumot használ, így biztosítható az adatok későbbi megnyitása 
is, míg egy-egy zárt kódú megoldásnál tapasztalható, hogy már a korábbi verziójú szoftver által 
elkészített adatok sem olvashatók hibátlanul. 
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2.7. Licencek 


A szoftverlicencek olyan jogok, amelyekért azért kell fizetnünk, hogy a kész, másoknak is eladott 
szoftverterméket korlátozott vagy jó esetben korlátlan ideig, korlátozott számban, területen használ- 
hassuk. Az ilyen fizetési kötelezettség mögött rejlő érdemi teljesítést sokan megkérdőjelezik. 

A licencelt szoftverek jellemzően meghatározott hardverre, általában egyszer, egy felhasználó 
számára telepíthetők, előfordul, hogy még hardverkulcsot is kell használni. Ezeket a programokat 
azonosító számuk alapján, pontosan, napra készen nyilván kell tartani. Ellenőrzéskor a legkisebb 
eltérés vagy hiányosság esetén is indokolatlanul nagy retorziókra kell számítani. 

Nagyobb rendszerek esetén a rendszergazdák azonos típusú konfigurációk telepítésére klónozási 
technológiát alkalmaz(ná)nak. Ezzel a megoldással a napokig tartó telepítgetések és beállítgatások 
pár perc alatt elvégezhetők. Sajnos az ilyen klónozási technológiák azt a veszélyt hordozzák, hogy 
a licencek sorozatszáma nem változtatható meg, így hiába van a felhasználó birtokában megfelelő 
számú licenc, a sorozatszámok eltérése miatt azokat nem jogszerűen használja. Az azonos időben 
beszerzett, azonos konfigurációk általában egyidejűleg hibásodnak meg, így a rendszergazdáknak 
az adminisztrációra is indokolatlanul nagy figyelmet kell fordítani. A feladatot nem oldják meg, 
legfeljebb könnyítik azok az alkalmazások, amelyek összegyűjtik a gépek tulajdonságait, hiszen a 
korábbi leltárral minden esetben egyeztetni kell az eltéréseket. 

Ezzel szemben a nyílt forráskódú szoftvereket nem szükséges az egyedi licenc- azonosítószám 
alapján egyenként nyilvántartani. A szoftverek általában mindenféle korlátozás nélkül telepíthetők, 
így nem kell aggódni lejárt, áttelepített, más gépen használt programok miatt. Nem kell a haszná- 
lati jogokat megújítani, és nem kell időközönként az adófizetők pénzéből újabb szoftverlicencekre 
költeni. 

A nyílt forráskódú szoftverek többségét nem kell online vagy telefonos ügyfélszolgálaton keresz- 
tül regisztrálni ahhoz, hogy működésre bírjuk, nem kell magyarázkodni, ha többször újra szeretnénk 
telepíteni az adott programot. 


2.8.  Vírusvédelem, biztonság 


Mint az ismeretes, feltörhetetlen rendszer nincs. Jóval kisebb azonban a nyílt forráskódú rendsze- 
reket érő támadások száma, legyen az vírus- vagy crackertámadás. A közösségek által fejlesztett 
rendszerek esetén "több szem többet lát" alapon javítják a hibákat, így a tapasztalatok azt mutatják, 
hogy jóval kevesebb hiba marad az ilyen rendszerekben, mint a zártakban, amikbe csak a fejlesztők 
látnak bele. Tapasztalat az is, hogy a nyílt rendszerekkel telepített kliensekkel gyakorlatilag nincs 
probléma a többi számítógéphez képest. 

Az ismert vírusok, férgek, trójaik nagyon nagy százaléka nem fut ezeken a rendszereken, így 
komoly vírusvédelmi rendszer árát is adott esetben meg lehet takarítani. 


3. A nyílt forráskódú rendszerek bevezetését gátló tényezők 


3.1. Az újtól, a nyílt forráskódtól való félelem, dolgozói ellenállás 


Általában igaz, hogy az emberek tartanak az újtól. A régi, megszokott dolgokat szeretik használni, 
beleértve a munkahelyükön használt szoftvereket is. A legtöbb esetben a váltástól való félelem alapja, 
hogy előítéletekkel fordulnak a megszokottól eltérő rendszerek felé, akkor is, ha azt egyáltalán nem 
ismerik ( kivételek ez alól a státuszszimbólumként funkcionáló eszközök, amiken mindegy milyen 
rendszer fut). A legtöbb dolgozó azt a generációt képviseli, akik még nem számítógépen szociali- 
zálódtak, így egy-egy szoftver használatának elsajátítása külön gondot okoz számukra. Ezek a dol- 


gozók különösen nagy aggodalommal hallják, ha egy rendszer "nyílt", mivel azt gondolják, hogy 
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így bárki belátást nyerhet a program által létrehozott adatokba, illetve információt nyerhet a kollé- 
gák egyéni munkájáról. Az ilyen feltételezések híre gyorsan elterjed, a felhasználók pedig együttes 
ellenállással képesek lehetnek a bevezetés ellehetetlenítésében. 

Az újtól való félelem nem csak a felhasználókat, de a legtöbb esetben a rendszergazdákat is érinti. 
A jól megszokott, könnyen telepíthető és használható szerverszoftverek, az ismert problémákkal 
küzdő kliens oldali operációs rendszerek az adott környezetben mindenképp kényelmet jelentenek. 
A közigazgatásban dolgozó régi vágású rendszergazdák közül sokan nem nyitottak az új kihívásokra, 
félelmeik vannak a jelenleg működő megoldások átültetésére egy újabb technológiai környezetbe. 
Sokan azzal magyarázzák a nyílt forráskódú rendszerekre történő áttéréstől való félelmüket, hogy 
nem kapnak megfelelő terméktámogatást a nyílt forráskódú rendszerekhez, illetve a megfelelő mi- 
nőségű szupport költségét kifizetve ugyanakkora költséget jelent, mint, ha megmaradtak volna az 
eredeti verzióknál. Hallottam már olyan indokot is, hogy egy esetleges meghibásodáskor nyílt kódú 
rendszerek használata esetén a felelősséget nincs kire áthárítani. 

Sajnos a tapasztalataink azt mutatják, hogy zárt kódú szoftverek használatakor felmerülő kisebb- 
nagyobb hibákat a helyi üzemeltetők is meg tudják oldani, a megold(hat)atlan problémára pedig a 
gyártó által nyújtott támogatás sem tud kielégítő válasszal szolgálni. A felelősség áthárítása érdeké- 
ben pedig célszerű a szoftverhez kapott tájékoztatót elolvasni: magam még sosem találkoztam olyan 
szoftverrel, amelynek a gyártója felelősséget vállalt volna a termék használatából eredő károkért. 

Összességében elmondható tehát, hogy azonos tudású szoftverek esetében általában a zárt és a 
nyílt kódú rendszerekhez ugyanúgy nem kapunk ingyen érdemi támogatást és felelősségvállalást, 
így a szoftverek között gyakorlatilag a termékek ára tesz különbséget. 


3.2. Kompatibilitási problémák 


A számítógépet közigazgatási alkalmazása során a legtöbb esetben egyszerűen az írógép kiváltására 
használják. A használt irodai alkalmazáscsomag "szokásjog" alapján az egyik legelterjedtebb gyártó 
drága szoftvere. Ennek a szoftvernek a folyamatos frissítése közigazgatási felhasználás szempontjá- 
ból semmiféle újdonságot nem tartalmaz, ugyanakkor a mindenkor legfrissebb változat használata 
szükségszerűen magával viszi a többi felhasználót is, mivel az eltérő verziók alapértelmezett for- 
mátuma jellemzően kompatibilitási problémákat okoz. Márpedig aki új szoftvert vásárol, egyrészt 
nem "bűvészkedik" az alapértelmezett formátum átállításával, másrészt nem is akarja a "rosszabb" 
formátumot használni, annak ellenére, hogy az új formátum érdemben nem nyújt új funkcionalitást. 
Sajnos ezekkel az alkalmazásokkal készített dokumentumok legtöbbször a korábbi verziójú progra- 
mokkal sem csereszabatosak, a nyílt forráskódú alternatíva pedig bármilyen tökéletes, konverziós 
hibák mindig maradnak a rendszerben. 

Megoldást az jelentene, ha minden állam- és közigazgatási szereplő szabványos formátumot 
használna a dokumentumok formátumának megválasztásakor. Így elkerülhetők lennének a kompati- 


4м: Z 


3.3.  Szigetalkalmazások és központi szoftverek használata 


Sok hivatalban az átállást nehezíti a régi, zárt rendszerek okozta függőség. A legtöbb ilyen rendszer — 
ahogyan korábban már szó esett erről – erősen platformfüggő. Ezekbe az évek során számos nélkü- 
lözhetetlen adat került, így az interoperabilitás megoldása illetve az adatmigrálás nehézkes és drága 
folyamat, legtöbbször csak hosszú párhuzamos üzem vagy a rendszer teljes avulása esetén történő 
csere jöhet számításba. Amíg a platformfüggő szoftverek meghatározzák az alkalmazott informatikai 
rendszert, addig sem szerver, sem kliens oldalon nem lehet teljes körű cserében gondolkodni. 

Az egyedileg gyártott szigetalkalmazásokon túl a közigazgatásban számos olyan központi szoft- 
ver használata kötelező, amelyek még régi, karakteres operációs rendszeren futnak. Ezeknek a prog- 
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ramoknak a futtatását meg lehet ugyan oldani emulátor programokkal, azonban a kifogástalan mű- 
ködésért senki nem vállalja a felelősséget. Hiba esetén nyilvánvaló, hogy a felelősséget arra fogják 
hárítani, aki a "nem megfelelő" környezetre ültette át aprogramot, függetlenül a hiba tényleges oká- 
tól. 

Több ilyen — szintén kötelező — szoftver már kiváltásra került, és az irány akár kedvező is lehetne, 
hiszen ezek többsége böngészőben fut, mégis az ilyen programok közül alig kettőről mondható el, 
hogy bármilyen operációs rendszeren, bármilyen böngészőben használható. Ennek oka, hogy a több- 
ségük vagy böngészőfüggő (például az alkalmazás által generált URL-ekben backslash található) 
vagy olyan bővítményt igényel, amelyet nem minden böngésző támogat. Nem csak az operációs 
rendszer kiváltását nehezítik azonban azok a központi szoftverek, amelyek használata eltérő verzió- 
számú bővítményeket igényelnek, hiszen ezek egyazon számítógépen történő futtatása még a nem 
nyílt forráskódú rendszerek használata esetén is komoly fejtörést okoz. 

A közigazgatási rendszerek egyik legfontosabb eleme az iktató program. A 24/2006 ВМ-ІНМ- 
NKÖM egységes rendelet alapján ezeket a szoftvereket tanúsíttatni kell. Nyilvánvaló, hogy olyan 
ingyenesen hozzáférhető iratkezelő rendszer megjelenése nem várható a piacon, amely a jogszabály 
szerinti mindenkori tanúsítással bír, hiszen a tanúsításnak folyamatosan jelentős financiális vonzata 
van. Megoldást jelent egy platformfüggetlen módon futó szoftver, mivel így legalább a járulékos 
költségek (amelyek jellemzően a kliens és szerver oldali szoftverlicencek) ára megtakaríthatóvá vá- 
lik. 


3.4. Nem támogatott hardver 


Gondot jelenthetnek a kliens oldali operációs rendszerek cseréjében a régi, nem támogatott hard- 
vereket (nyomtatókat, szkennereket, fényképezőgépeket stb.) működésre bírni. Az átállás ebben az 
esetben erősen függ a későbbiek során megvásárolandó platformfüggetlen működéssel bíró eszkö- 
zök beszerzésének időpontjától. 


4. Megoldások 


Ahogy a bevezetőben megfogalmazásra került, a közigazgatási folyamatok támogatását nyújtó szoft- 
verekkel szemben támasztott elvárások jellemzően nem túl magasak. Általában szövegszerkesztő 
programra, számolótáblákra, elektronikus levelezőrendszerre, internet böngésző programra van szük- 
ség. Drága tervező és szerkesztő programokat nem, vagy csak korlátozott számban használnak. A 
speciális igényeket kielégítő backoffice szoftverek nagy többségükben tipizálhatók. Ha a felsorolt 
szoftvereket sikerül platformfüggetlen módon futtatni, a kliens oldali operációs rendszerek és iro- 
dai alkalmazáscsomagok gond nélkül cserélhetők nyílt forráskódúra, amivel a szegedi tapasztalatok 
szerint több száz millió forint megtakarítás érhető el egy-egy nagyobb hivatalban. 

Szerver oldali megoldásoknál eddig is jóval több nyílt forráskódú szoftverrel találkozhattunk, 
gyakorlatilag minden informatikai problémára létezik megbízható, jól működő nyílt forráskódú al- 
ternatíva. 

A legkézenfekvőbb megoldásnak az alkalmazásszolgáltató központ(ok) (ASP) létrehozása tűnik, 
ahol központilag futtatott, vékonykliens vagy böngészőben futó platformfüggetlen megoldásokat 
kapnának a közigazgatási szervek. Így— többek között—a teljes magyar közigazgatás kliens oldali 
szoftver ráfordításai megtakaríthatók lennének. 

Szeged Megyei Jogú Város Önkormányzata rendelkezik olyan, saját tulajdonban lévő, alkalma- 
zásszolgáltatásra is alkalmas integrált önkormányzati rendszerrel, amely az önkormányzatok felada- 
tainak nagy részét támogatja. Szerver oldalon csak nyílt forráskódú megoldásokat igényel, kliens 
oldalon pedig platformfüggetlen módon böngészőben fut. 
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Szeged M. J. Város Közgyűlése a 454/2010. (VIII.13.) Kgy. sz. határozatában országos ASP 
központ létrehozása esetére felajánlotta az e-önkormányzati rendszerét a Magyar Köztársaság Kor- 
mánya és önkormányzatai számára ingyenes felhasználásra. 
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1. A kezdetektől a nyílt forrásig 


A LibreOffice projekt 2010. szeptember 28-án indult el, de köztudott, hogy nem a semmiből tűnt elő. 
A programcsomag történetét 1985-ig vezethetjük vissza, ebben az évben alapította meg az ekkor 16 
éves Mark Börries a Star Division nevű szoftverfejlesztő céget Németországban. A Star Division 
1986-ban kezdte el fejleszteni a StarWriter szövegszerkesztőt az akkori legelterjedtebb, PC-n futó 
operációs rendszerre, DOS-ra. Az 1990-es évek elején megszületett a termék windowsos, majd О$/2- 
es és Mac-es verziója, a StarWriter mellé elkészítették a StarCalc táblázatkezelőt, a StarChart grafi- 
konkészítőt, a StarDraw vektoros rajzolóprogramot és a Ѕїагітаре bitképes rajzolóprogramot, és az 
egész csomagot StarOffice néven hozták forgalomba. A StarOffice 3.1-es verziója 1996-ban jelent 
meg, ez a változat már egy böngészőt és egy HTML-szerkesztőt is tartalmazott. A StarOffice 1997- 
ben vált teljes irodai csomaggá, amikor már bemutatókészítőt (StarImpress) és adatbázis-kezelőt 
(StarBase) is tartalmazott. 

A Star Division önálló élete 1999-ben ért véget, amikor a Sun Microsystems 73,5 millió dollár- 
ért felvásárolta a céget. Simon Phippstől — aki akkoriban a Sun alkalmazottja volt — származik egy 
anekdota a felvásárlás okáról. Akkoriban a Sunnak kb. 42 ezer alkalmazottja volt. Nagy részüknek 
volt unixos munkaállomása és windowsos laptopja is. Olcsóbb volt venni egy olyan céget, amely Li- 
nux és Solaris környezetben is működő terméket állított elő, mint vásárolni 42 ezer Microsoft Office 
licencet a Microsofttól. Vagy nagyon drága volt 1999-ben egy Microsoft Office licenc, vagy Simon 
Phipps kicsit kiszínezte a történetet, esetleg nem is ezt mondta, de tény az, hogy az üzlet létrejött. 
A Sun a Microsoft Office versenytársává akarta tenni a terméket. Első intézkedésként ingyenesen 
letölthetővé tették a StarOffice 5.2-es verzióját. 


2. Az OpenOffice.org felemelkedése és bukása 


Az ezredforduló táján a nyílt forrású, illetve szabad szoftverek már komoly sikereket értek el, az 
üzleti élet is felfigyelt erre. A nyílt forrású fejlesztési modell szimpatikus volt néhány vállalatnak, 
ezek sorába lépett be a Sun is, amikor elkezdte megtisztítani a StarOffice kódbázisát a harmadik fél 
szerzői joga alatt álló elemektől, és végül 2000. október 13-án OpenOffice.org néven szabaddá tette 
az irodai csomag forráskódját LGPL/SISSL kettős licenc alatt. Az LGPL a Free Software Founda- 
tion által kiadott GNU Lesser General Public License, biztosítja a négy legfontosabb szabadságjogot, 
a kód szabad felhasználását tetszőleges célra, a kód tanulmányozásának és módosításának jogát, a 
szabad továbbterjesztés jogát, illetve a módosított verziók továbbadásának jogát. A SISSL a Sun 
Industry Standards Source License rövidítése, ezt a Sun fejlesztette ki. A SISSL egy gyenge copy- 
left típusú licenc, amely megengedi a származtatott munkák forráskódjának bezárását. 2005-ben az 
OpenOffice.org 2.0 már csak LGPL alatt jelent meg, a SISSL választhatósága megszűnt. 

Eredetileg az OpenOffice nevet szerették volna adni a projektnek, de sajnos néhány országban ez 
a név már védett volt. Így lett az internetes tartománynév a projekt és a termék neve is. Körülbelül 
másfél évet vett igénybe, míg a szabaddá tett forráskódból egy vállalható terméket sikerült előállítani, 
ez kapta az 1.0-s verziószámot. A Star Division megszűnt, mint önálló cég, de megmaradt, mint a 
Sunon belüli önálló üzleti egység. Az OpenOffice.org fejlesztését továbbra is ez a társaság tartotta 
kézben. 

Bár 2000-ben még olyan nyilatkozat látott napvilágot, hogy a Sun egy független alapítvány ke- 
zébe adná a forráskódot és a jogokat, a nyílt forráskódú fejlesztési modellt inkább úgy képzelték 
el, hogy az irányítást és a jogokat maguknak megtartva közösséget szerveznek a termék köré, és 
a saját fejlesztőkön kívül a külsős fejlesztők ingyenes munkáját is beépítik a termékbe. Bevételt az 
OpenOffice.org kereskedelmi verziójának, a StarOffice-nak a licencdíjából és a hozzá eladott termék- 
támogatási szerződésekből reméltek. Kiderült azonban, hogy egy nyílt forrású projekten dolgozó fej- 
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lesztőközösség létrehozásához nem elég а kódot megnyitni. Az első években külsős fejlesztőtől nem 
érkezett jelentősnek mondható kódhozzájárulás, a Sunon kívüli közösség szerepe inkább a honosítá- 
sokban, a minőségbiztosításban és a dokumentációírásban domborodott ki. Az okok sokfélék. A Star 
Division Team vállalati kultúrájától idegen volt a nyílt forrású fejlesztés dinamizmusa, sokszínűsége. 
A forráskód módosításainak (patchek vagy magyarul foltok) befogadása extrém lassú volt. A külsős 
fejlesztők elé bürokratikus és technikai akadályokat állítottak, például: bonyolult specifikációs doku- 
mentum kitöltése, elfogadtatása egy bizottság által, teszt build készítése legalább két platformra. A 
sikertelenséget látva próbáltak javítani a folyamatokon, némi sikerrel, de nemcsak ez volt a probléma. 
A szerzői jogok Sunnal való kötelező megosztása gondot okozott néhány egyéni hozzájárulónak is, 
de az OpenOffice.org-ban érdekelt, azonban a Sun versenytársának számító vállalatoknak végképp. 

A fejlesztés így több ágra szakadt, és az egységes, közös munka helyett az egyes szállítók maguk- 
ban dolgoztak. Egyesek megmaradtak a nyílt forrásnál. Például ilyen volt a Go-OO fork, amely kb. 
800 saját foltot tett az OpenOffice.org forráskódjához. Szinte minden Linux-disztribúció ezt hasz- 
пайа, és ezen alapult a Novell saját ügyfeleinek szállított windowsos buildje is. Mások kihasználták 
a SISSL által biztosított jogot, és nem adták ki saját kódjaikat (részleteket esetleg igen), például így 
tett az IBM a Symphonyval vagy a magyar Multiráció Kft. a MagyarOffice/EuroOffice programcso- 
maggal. 

2010-ben az Oracle felvásárolta a Sunt, és így az OpenOffice.org forráskódja és a Star Division 
Team is a birtokába került. A StarOffice-t Oracle Open Office-ra nevezték át, és megnyugtatták ügy- 
feleiket és a közvéleményt, hogy a fejlesztés folytatódik. Viszont a Sun által 2000-ben megígért, 
hallani, pontosabban az ezt firtató kérdésekre kitérő válaszokat adtak. A közösség egyes prominens 
tagjaiban ekkor megérett az elhatározás: lépni kell, nem várhatnak az Oracle-re. Elkezdték titokban 
kidolgozni a független OpenOffice.org alapítvány terveit. A 2010-es OpenOffice.org konferencia 
Budapesten volt, és szeptember 2-án este, míg az Oracle-csapat és a mit sem sejtő többi résztvevő a 
Dunán hajókázott, 16 ember egy étteremben véglegesítette az alapítvány irányelveit, és megválasz- 
totta az első, ideiglenes vezetőségét. 2010. szeptember 28-án jelentették be: megalakult a Document 
Foundation, és az általa támogatott, OpenOffice.org-ra alapuló termék neve ezentúl LibreOffice, mi- 
vel az OpenOffice.org név birtokosa az Oracle. 

Az Oracle a meghívás ellenére nem csatlakozott Document Foundationhöz. Folytatták az Open- 
Office.org fejlesztését. 2011 áprilisában azonban beszüntették a kereskedelmi verzió támogatását, és 
mint később nyilvánvalóvá lett, megkezdődött a Star Division Team leépítése. Mostanra (2011. no- 
vember) már senki nem dolgozik az Oracle-nél OpenOffice.org-on. A Star Division Team megszű- 
nése mindenképp nagy veszteség. Bár hozzáállásukkal időnként bosszúságot okoztak, sok fejlesztő 
a kezdetek óta részt vett a projektben, pótolhatatlan tudásra és tapasztalatra téve szert. Szerencsére 
néhányukat felvette a Red Hat, ők LibreOffice-t fognak fejleszteni. Mások az IBM-nél folytatták 
pályafutásukat, talán az ő munkájukból is profitál majd a közösség. 

Az Oracle az OpenOffice.org forráskódját sajnos nem a Document Foundationnek, hanem az 
Apache Foundationnek adta át, ezért sajnos az OpenOffice.org és a LibreOffice újraegyesülése el- 
maradt, és nem is lesz lehetséges az eltérő licencelés miatt. Kétséges azonban, hogy az Apache 
OpenOffice.org mennyire lehet életképes. Jelenleg több súlyos problémájuk van. A projektben részt 
vevő úgynevezett committerek között kevés a programozó, márpedig a fejlesztés programozók nél- 
kül nem lehetséges. A teljes infrastruktúrát migrálniuk kell az Apache rendszere alá. Az Apache 
által választott verziókezelő, az svn, visszalépés az eddig használt mercurialhoz képest. Az Apache 
licenccel nem kompatibilis (pl. LGPL) licencű függőségeket ki kell váltaniuk, elég sok ilyen van. 
Például a Németh László által fejlesztett helyesírás-ellenőrző, a Hunspell is ilyen. Az Apache nem 
gazdája a projektnek, csak az infrastruktúrát és az ideológiát adja, a termék fejlesztése és a kiadása 
a fejlesztői közösség feladata. Azon múlik tehát a sikerük, hogy lesz-e elég fejlesztőjük. De miért 
akarna egy független fejlesztő az Apache OpenOffice.org-hoz csatlakozni, amikor a már bizonyított 
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3 A LIBREOFFICE ELINDULÁSA 





LibreOffice projektben — egy év alatt 9 stabil kiadás — is könnyen megvalósíthatja elképzeléseit. . . 


3. А LibreOffice elindulása 


Kanyarodjunk vissza a 2010 szeptemberi eseményekhez, a LibreOffice elindulásához. A Document 
Foundation és a LibreOffice tulajdonképpen egy kísérlet. Kísérlet arra, hogy bebizonyosodjon, hogy 
a szabad szoftveres fejlesztési módszertanok egy ekkora kódbázis esetén is alkalmazhatók, és üzleti 
szempontból is sikeres termék állítható elő. A kérdés az, hogy vajon lehet-e egy olyan irodai prog- 
ramcsomagot készíteni, amelyre a fejlesztői büszkék lehetnek, és amely mögött egy valódi, nyílt 
közösség áll. 


A Document Foundation fontosnak tartja, hogy a LibreOffice független legyen a gyártóktól, il- 
letve szállítóktól. A LibreOffice fejlesztői és támogatói bázisa sokszínű. Fejlesztőket ad a Novell 
(15), a Red Hat (5), a Canonical (1), a Debian (1), és folytathatnánk még a sort sok kisebb, kevésbé 
ismert vállalattal, illetve a több száz önkéntessel. A Google a Summer of Code projekten keresztül 
támogatja, 2011-ben hét egyetemista dolgozott a LibreOffice-on. A forráskód git repositoryja és a 
fejlesztői levelezőlista a freedesktop.org-on van. Elvi támogatást ad az FSF és a vele sok kérdésben 
szemben álló OSI. Még a , Boycott Novell" is üdvözölte a LibreOffice-t a Novell jelentős részvétele 
ellenére! 


Fontos változás a Sun/Oracle időkhöz képest, hogy a LibreOffice-hoz való hozzájárulás esetén 
nincs szerzőijog-megosztás. Az új hozzájárulók munkája MPL/LGPLv3- licenc alatt kerülhet be, 
de a szerzői jogokkal minden hozzájáruló maga rendelkezik. Ez nehézzé, csaknem lehetetlenné teszi 
például a licenc megváltoztatását, adott esetben ez hátrány is lehet. Azonban a szerzői jog megosz- 
tása nélkül a hozzájárulók nagyobb biztonságban érezhetik hozzájárulásukat, nem lehet kisajátítani 
azt. Arról nem is beszélve, hogy a projekthez csatlakozás sokkal egyszerűbb, a folt beküldése és a 
licenc elfogadása ugyanabban az e-mailben megtörténhet, nem kell aláírni, faxolni, levelet küldeni, 
jóváhagyásra várni stb. Az eredmény kézzel fogható. A LibreOffice több egyéni, önkéntes kódhoz- 
zájárulót vonzott magához egy év alatt, mint az OpenOffice.org az első 10 évben. 


Az új hozzájárulók akkor kezdenek el szívesen dolgozni egy projekten, ha könnyű bekapcsolódni, 
és hamar sikerélményhez jutnak. Az OpenOffice.org-tól megörökölt forráskód azonban legendásan 
ronda. Ezért a LibreOffice projekt indulásának első napján elkezdődött egy masszív kódtisztítási fo- 
lyamat, amely máig tart, és még sokáig fog munkát adni, de megéri, mert a fejlesztők saját későbbi 
munkájukat könnyítik meg vele. Mellékhatásként a program gyorsabb lesz, és kevesebb memóriát 
foglal. A forráskód egy jó része régi, akár 20-nál is több éves. Organikusan növekedett, a refakto- 
rálást hanyagolták. A kor miatt egy régebbi C++-nyelvállapot figyelhető meg, a standard könyvtár 
20 évvel ezelőtti nemléte miatti saját fejlesztésű alaposztályokkal, egy feladatra akár több párhuza- 
mosan létező osztállyal is. A fejlesztők kedvelt eszköze volt a copykpaste, aminek folyományaként 
előfordul, hogy egy hibajavítás nincs minden helyen átvezetve. A forráskódba szúrt megjegyzések 
jelentős része németül van, annak ellenére, hogy a kód már 11 éve nyitott. Sok kódrészlet felesleges, 
futás közben soha nem adódik rá a vezérlés, vagy túlbonyolított a rég nem támogatott platformokat 
(Alpha, OS/2, Windows 3.1, Windows 9х) kezelő kódok miatt. Ezek a kódtisztítási feladatok sokszor 
egyszerűek, csak egy kis szorgalmat igényelnek. Az ilyen és más belépő szintű feladatok gyűjtemé- 
nye az Easy Hacks. Sok új fejlesztő kezdte ezzel, és ismerkedett meg ezen keresztül a kódbázissal. 
Érdemes rákeresni az interneten az , Easy Hacks LibreOffice" kulcsszavakra, talán e cikk olvasója is 
talál ott magának való feladatot. . . 
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4. Középpontban а fejlesztők 


Egy szabad szoftvert fejlesztő projektben sokféle szerepe lehet a hozzájárulóknak. Nagyon hasznos 
munkát végeznek a tesztelők, a honosítók, a dokumentációírók, a designerek, a webmesterek, az 
infrastruktúrát üzemeltető rendszergazdák vagy akár a marketingesek. Mindazonáltal a szoftverfej- 
lesztés lényegéből adódóan a legfontosabb tevékenység mégiscsak a kódírás. Új kód nélkül nincs 
fejlődés, és a többiek munkája is értelmetlenné válik. A LibreOffice fejlesztésén kb. 30 főállású fej- 
lesztő dolgozik, de nyilvánvaló, hogy ez a létszám kevés a több millió kódsor karbantartására, a hibák 
javítására és új funkciók fejlesztésére. A Document Foundation nagyon nagy hangsúlyt fektet az új 
kódhozzájárulók megnyerésére és megtartására. Már említettük, hogy nem kell aláírni a szerzőijog- 
megosztási nyilatkozatot, ez jelentősen leszállította a belépési korlátot. További könnyebbség, és a 
bürokrácia visszavágása, hogy nem szükséges a folthoz hibajegyet nyitni a Bugzillában. Elegendő 
a foltot e-mailben elküldeni a fejlesztői levelezőlistára, nyilatkozni a licencről (MPL/LGPLv3--) és 
kész. A folt akár aznap bekerül a gitbe. A harmadik-negyedik jó folt után a hozzájárulónak felajánl- 
ják az írásjogot, innentől maga dolgozhat. Ezt sokan kockázatosnak ítélhetik, mert mi van, ha valami 
rosszat csinál egy új, ismeretlen hozzájáruló. A gyakorlatban azonban az előnyök felülmúlják az eset- 
leges hátrányokat. A múlt tapasztalata az volt, hogy a szigorú ellenőrzés kontraproduktív. Meg kell 
bízni a hozzájárulókban, hinni kell, hogy tudják, hogy mit csinálnak. Az esetleges hibákat később 
javíthatók, a git logból egyértelműen visszakövethető minden változtatás. 


Sok (kezdő) szoftverfejlesztő félénk, introvertált típus, nehezen szánja rá magát, hogy elküldje 
egy projektnek első munkáját, mert tart attól, hogy a tapasztalt fejlesztők leszólják. A LibreOffice- 
nál nagyon odafigyelnek arra, hogy ne riasszák el az új hozzájárulókat. Nem illik leszólni egy kezdő 
munkáját, az az ő , gyermeke , neki valószínűleg tetszik. A fanyalgás — jó, jó, de lehetne jobb — is azt 
eredményezi, hogy az illető nem küld többet semmit. Sokkal jobb rögtön megdicsérni: , Nagyszerű, 
hogy küldted ezt a foltot, máris betettük a gitbe, egy kicsit kellett még reszelni rajta, nézd meg a 
logban, de nagyon köszönjük, hogy segítettél jobbá tenni a LibreOffice-t. Mi lesz a következő téma, 
amivel foglalkozni szeretnél? Gyere fel az IRC-re is, stb." A legtöbb ember fejlődőképes. Megéri az 
elején egy kis energiát fektetni a kedves fogadtatásba és az esetleges hiányosságok javításába, mert 
a további hozzájárulások valószínűleg egyre jobbak lesznek. Később a hozzájáruló maga is egy új 
hozzájáruló mentora lehet, és ezt a pozitív felfogást adja tovább. 


A fejlesztői levelezőlistán és az IRC-n a pozitív hozzáállás azonban csak azokra vonatkozik, akik 
kódot küldenek vagy szeretnének küldeni. Vannak akik megírják a jó ötletüket, hogy mit kellene 
megvalósítani. Mások felháborodottan írnak, hogy addig számukra használhatatlan a LibreOffice, 
amíg ez meg az a hiba nincs javítva, és hogyhogy nincs, és hogy lehet így kiadni stb. A helyzet az, 
hogy ötletekkel , tele a padlás". Rengeteg ötlete van a fejlesztőknek is. Ami kevés, az az erőforrás 
mindezen ötletek megvalósításához. Nem kellenek a kóddal alá nem támasztott új ötletek. Új fejlesz- 
tők kellenek. Ami a hibákat illeti, hetente átlagosan bejelentenek 100-at és javítanak 10-et. Látható, 
hogy nincs egyensúly. A hibajavításnál előnyt élveznek a fizetős ügyfelek hibái, legalábbis ami a 
fizetett fejlesztőket illeti. A kiadások időalapúak. Természetesen nem jelenik meg a kiadás, ha fel 
sem telepíthető, vagy el sem indul, vagy nem lehet semmilyen dokumentumot betölteni, de nem kri- 
tikus hibával megjelenik, és az ismert hibák a kiadási megjegyzésben fel lesznek sorolva. Nyilván 
minden kiadás tartalmaz ismeretlen hibákat is. Ezek akkor jönnek elő, amikor a felhasználók hasz- 
nálni kezdik a programot. Az a típusú fenyegetőzés, hogy , javítsátok a hibámat, mert különben nem 
használom — az amúgy ingyen közreadott — programot", egyszerűen nevetséges. Volt olyan fejlesztő, 
aki félig viccesen azt mondta, hogy annyi hiba van már bejelentve, hogy nem kell több, a meglé- 
vőkkel is ellennénk a következő pár évben. Természetesen nem minden hiba egyformán súlyos. A 
reprodukálható programösszeomlásokat vagy a regressziókat mindenképp érdemes bejelenteni. 
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6 AZ ÜZLETI MODELL 





5. A Document Foundation 


2010 szeptemberében megalakult a Document Foundation (TDF). Az alapítók az OpenOffice.org kö- 
zösség vezetői közül kerültek ki, pontosabban azok közösségi vezetők határozták el az alapítvány lét- 
rehozását, akik nem voltak Oracle-alkalmazottak. A bejelentést követő hetekben az OpenOffice.org 
közösségből szinte mindenki, aki nem az Oracle-nél dolgozott, bejelentette hogy csatlakozni kíván 
a TDF-hez. A TDF alapítói lefektették az azóta is érvényes alapelveket, tanulva a múlt hibáiból, más 
sikeres szervezeteket megfigyelve és megpróbálva megalkotni a tökéletes szabad szoftveres szerve- 
Zetet. 

A TDF független. Ez nem azt jelenti, hogy tagja vagy vezetői között nincsenek jelen a LibreOffice- 
ban érdekelt vállalatok alkalmazottai. Minden érdekelt fél jelen van, de a különböző vezető testüle- 
tekben egyiknek sem lehet 1/3-nál nagyobb részesedése. A LibreOffice jövője nem egyetlen szpon- 
zor kezében van, a fejlesztőközösség sokszínű és kiegyensúlyozott. 

A TDF meritokratikus. Ez azt jelenti, hogy annak van nagyobb szava, aki többet tesz le az asz- 
talra. Ez logikus, hogy így van, összhangban van azzal az elvvel, hogy azok vezessék a projektet, 
akik fejlesztik. A TDF tagja az lehet, aki jelentős hozzájárulással segítette a LibreOffice-t. Ez le- 
het bármi, fejlesztés, honosítás, dokumentációírás, marketing stb. A tagság elnyeréséhez legalább 
3 hónapos , múltat" kell igazolni, egyúttal vállalni kell további 6 hónap aktív közreműködést. Egy 
vagy két ajánlóra is szükség van a tagsági kérelem elbírálásakor. A tagoknak választójoguk van és 
választhatók is a TDF vezető testületeibe. 2011 októberében zajlott le az első választás, a TDF-et 
irányító 7 tagú (+3 póttag) igazgatótanácsot választotta meg a tagság. Az igazgatótanács feladata а 
közösség építése, irányítása, a hivatalos (hatósági) ügyek intézése, az adománygyűjtés, a pénzügyek 
kezelése és a stratégiaalkotás. Azonban LibreOffice fejlesztését illető kérdéseket eldöntő Engine- 
ering Steering Comittee tagjait nem a tagság választja, hanem a fejlesztők maguk közül jelölik ki, 
így nem fordulhat elő, hogy olyasmit szavaz meg a tagság, amit nem lehet megvalósítani vagy ellen- 
kezik a projekten dolgozó fejlesztők elképzeléseivel. A tagnak jelentkezés folyamatos. Az elutasított 
embereknek ismét jelentkezhetnek, ha jobban alá tudják támasztani jelentkezésük jogosságát. 

Jelenleg a TDF nem jogi személy, nincs bejegyezve sehol. A TDF képviseletét egy német non- 
profit szervezet, az OpenOffice.org Deutschland e.V. látja el, ők fizetik a számlákat, ők fogadják 
a beérkező adományokat. A TDF alapításakor szándékosan nem rögzítették le a szervezeti formát, 
hogy akik csatlakozni szerettek volna, szabadon alakíthassák ki a közös véleményüket erről. Az 
előkészületek kicsit több időt vettek igénybe a vártnál, de a cél egy nagyon stabil és megbízható 
szervezet létrehozása volt, ehhez sok erőfeszítés volt szükséges. A TDF ideiglenes vezetősége több 
lehetőséget is áttekintett, és végül az a döntés született, hogy az alapítvány szervezeti formája a 
német jog szerinti , Stiftung" legyen. A TDF németországi bejegyzéséhez minimum 50000 euró 
volt szükséges. Ezért elindítottak egy nyilvános adománygyűjtő kampányt, hogy az adományokból 
szedjék össze az 50 000 eurót. Körülbelül egy hónapot adtak a pénz összegyűjtésére. Sikertelenség 
esetén az Egyesült Királyságba vitték volna át a székhelyet, kicsit más jogi feltételek mellett. Az 
50 000 euró azonban mindenki meglepetésére 8 nap alatt összejött, sőt az adományozók nem álltak 
le, körülbelül a kétszer ennyi gyűlt össze az adománygyűjtési időszak végére. Megkezdődtek a tár- 
gyalások az egyes német szövetségi államokkal, hogy kiderüljön, hogy melyikben lenne a legjobb 
helyen az alapítvány. Jelenleg annyi publikus, hogy 3 szövetségi állam , van még versenyben", 2011 
végére valószínűleg minden eldől, és a TDF be lesz jegyezve. 


6. Az üzleti modell 


A LibreOffice fejlesztésében több profitorientált vállalat is érdekelt. Az üzleti modell a klasszikus 
nyílt forrású modell. A vállalatok által fizetett fejlesztők és az ingyen dolgozó önkéntesek együtt 
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dolgoznak а LibreOffice fejlesztésén. Az eredményekhez mindenki hozzájuthat az LGPL licenc fel- 
tételeinek megfelelően — akár ingyen. A LibreOffice-t fejlesztő vállalatok ügyfeleiknek 3. szintű 
(L3) terméktámogatást tudnak biztosítani, azaz képesek az ügyfélnél jelentkező hibákat a forráskód 
javításával megszüntetni. Az L3-as támogatás pénzbe kerül, általában a felhasználószámmal arányos 
éves előfizetési díjért vehető igénybe. 

A TDF minden intézményi felhasználónak melegen ajánlja, hogy vegye igénybe a LibreOffice-t 
fejlesztő valamelyik vállalat által nyújtott L3-as terméktámogatási szolgáltatást. Ez kölcsönös elő- 
nyökkel jár. Először is, az előfizetési díj még mindig sokkal olcsóbb, mint a versenytárs irodai 
csomagok licencdíja. Másodszor, sok bosszúságtól kíméli meg magát a szervezet, ha kidolgozott 
módszertan alapján kerül bevezetésre a LibreOffice, nem ad hoc módon. Harmadszor, a bevezetés 
és a használat során felmerülő hibákat a fejlesztők kijavítják. Fontos hangsúlyozni, hogy az lehe- 
tetlen, hogy hibabejelentő rendszerbe bejelentett minden hibával — mind a 2500 nyitott hibajeggyel 
— foglalkozzanak. Az viszont nagyon is lehetséges, hogy egy adott szervezetnél jelentkező, a napi 
használatot akadályozó 15-20 hibát kijavítsák. Nincs olyan felhasználó, akit minden hiba érint. A 
pénzéért cserébe a fejlesztők az ő hibáját fogják kijavítani. Negyedszer, ha mindenki ingyen veszi 
igénybe a fejlesztőközösség munkáját, akkor nem lesz bevétel, nem lesznek fizetett fejlesztők, és a 
LibreOffice fejlesztése óhatatlanul lelassul. Hosszú távon ezzel mindenki veszítene. 

A TDF a jövő évtől kezdve hivatalos partneri kapcsolatot épít ki minden vállalattal, akik képesek 
L3-as szintű terméktámogatást nyújtani. A potenciális ügyfelek rájuk találhatnak majd a ТОЕ, illetve 
a LibreOffice honlapján keresztül. Ennek a , reklámozásnak" azonban az a feltétele, hogy az illető 
vállalat bizonyítsa, hogy képes az L3-as szintű terméktámogatásra. Ezt csak egyféleképpen lehet 
bizonyítani: javítófoltok beküldésével. A TDF azzal lép szövetségre, aki elfogadja a nyílt fejlesztési 
modellt, és nemcsak elvesz, hanem vissza is ad. 

Magyarországon például a Novell nyújt L3 szintű terméktámogatást a LibreOffice-ra. A Novell 
magyarországi konzultációs részlege több ezer fős szervezeteknél végzett felmérési és bevezetési 
projektek során kialakult módszertannal felméri az aktuálisan használt irodai szoftverek használatát, 
javaslatot tesz és költségbecslést készít az átállásra, utána elvégzi a bevezetést fejlesztői támoga- 
tással, igény szerint forráskód módosítással. A hibajavításokat a 15 fős SUSE LibreOffice Team 
végzi, amely messze a legnagyobb LibreOffice-os fejlesztőcsapat a többi TDF-partner vállalatéhoz 
viszonyítva. Nemcsak a SUSE saját fejlesztésű Linuxán a SUSE Enterprise Desktopon, hanem Win- 
dowson is támogatott a LibreOffice, jelenleg a 3.4-es verzió. 
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1 AZ UBUNTU 





1. Az Ubuntu 


Hét év telt el azóta, hogy 2004 októberében megjelent egy új, Debian alapokra épülő GNU/Linux 
disztribúció, az Ubuntu. Az azóta eltelt időben a disztribúció óriási népszerűségre tett szert a fel- 
használók körében, és ugyan a Linux desktop éve továbbra sem köszöntött be, az Ubuntu mégis 
sikeresen bekerült a köztudatba Magyarországon is: az informatikai portálok rendszeresen foglal- 
koznak az Ubuntuval kapcsolatos fejleményekkel, és egy-egy új kiadás megjelenéséről a nagyobb 
híroldalak is beszámolnak. Az Ubuntu lassan a közszférában is kezd teret nyerni, egyre több hazai 
önkormányzatnál, közoktatási és felsőoktatási intézményben használják aktívan. 


> 


Я 
2 
5 
0 
#7 





0 


А rendszer óriási fejlődésen ment keresztül az első kiadás 2004-es megjelenése шап: az elmúlt 
hét évben 15 Ubuntu kiadás jelent meg, melyek mind újabb és újabb fejlesztéseket, szolgáltatásokat 
vezettek be. Az Ubuntu által követett fejlesztési modell alapvetően két, egymásra épülő szakaszból 
áll: az egyes új kiadások fél éves ciklusokban (minden tavasszal és ősszel) követik egymást. Két 
évente pedig az úgynevezett LTS (Long Term Support), vagyis hosszú távon támogatott kiadások 
következnek, melyek egyben fontos mérföldköveket jelentenek a disztribúció életében. A fejlesz- 
tők célja, hogy a két évente megjelenő LTS kiadások idejére a normál kiadásokban megalapozott 
fejlesztések kiforrottak és jól működők legyenek. Ez már csak azért is kritikus, mert az Ubuntu kö- 
vetkező, várhatóan 2012 áprilisában megjelenő LTS kiadása 5 éves támogatást kap kiszolgálókon és 
desktopokon egyaránt, így nem mindegy, mennyire nyújt majd ehhez stabil alapot a rendszer. 


Az Ubuntu rendkívül gyors fejlesztési üteméből következik, hogy a rendszer hálás témát nyújt 
mindazoknak, akik fogékonyak az újdonságokra. Az Ubuntu a kezdetektől fogva nagy hangsúlyt 
fektetett arra, hogy az új fejlesztéseket azonnal elérhetővé tegyék az érdeklődők számára, amint 
azok valamilyen szinten működőképesek, vagy legalábbis elindulnak: az Ubuntu fejlesztés alatt álló 
kiadása már a fejlesztési ciklus legelejétől elérhető tesztelésre, így a bátrabb felhasználók folyama- 
tosan nyomon követhetik, ahogy egy-egy kiadás formálódik a fejlesztési ciklus alatt. Természetesen 
ezek a fejlesztői kiadások nem alkalmasak éles használatra, de (akár napi szintű) tesztelésre tökéle- 
tesek, és nagyon nagy segítséget jelentenek azok számára, akik nem csak hírportálokon szeretnek 
olvasni az újdonságokról, hanem szeretik ki is próbálni azokat (és szívesen találkoznak elsőként a 
fejlesztői kiadásokkal járó bugokkal). 
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2. A Unity 


Az Ubuntu történetének eddigi legjelentősebb változására 2011 áprilisában került sor: ekkor vezet- 
ték be az új, Unity elnevezésű felhasználói felületet. A Unity egy új generációs felhasználói felület, 
melyet eleve úgy kezdtek el tervezni, hogy a későbbiekben a klasszikus, billentyűzettel és egérrel 
rendelkező számítógépek mellett érintőképernyős eszközökön is megállja a helyét. Ez nem azt je- 
lenti, hogy a felületet kifejezetten táblagépekre szánták: a fejlesztés első szakaszában elsősorban 
a klasszikus gépekre (asztali munkaállomás, notebook és netbook) fókuszáltak, és a tervek szerint 
csak a 2012. áprilisi Ubuntu kiadás megjelenése után kezdenek bele az újabb eszközök ( például 
táblagépek) magasabb szintű támogatásába. 
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A Unity első, kipróbálható verzióját 2010. május 10-én tették elérhetővé egy tárolóból, amit fel- 
véve bárki telepíthette ezt a korai változatot a saját számítógépére. A Unity legelső verziója, bár 
működött, jóval kevesebb funkciót nyújtott, mint ma. A fejlesztők az azóta eltelt másfél év során 
rendkívül komoly fejlesztési ütemet diktáltak. A Unity az Ubuntu 10.10 Netbook Edition változat- 
ban vált először alapértelmezett felületté. Ekkor még a felület a GNOME Shell ablakkezelőjét, a 
Muttert használta, az Ubuntu 10.10 megjelenése után azonban teljesítményproblémák miatt portol- 
ták a felületet az Ubuntu által korábban is használt Compizra. A látványos effektusokat biztosító 
ablakkezelő az Ubuntu 7.10-es kiadásában lett alapértelmezett a grafikus gyorsítást támogató gé- 
peken, így már volt ideje bizonyítani, hogy megfelelően gyors és stabil. Hogy a munka zavartalan 
legyen, a Canonical az egyik Compiz fejlesztőt, Sam Spillsburyt alkalmazta. 


3. A Unity felépítése és működése 


A Unity hardveres grafikus gyorsítást használó változata, a Unity 3D Compiz pluginként készült 
el. A hardveres támogatással nem rendelkező gépeken a Unity 2D indul el, amely a Ot eszköz- 
készletet használja, és a OML elnevezésű, felhasználói felületek készítését nagyban megkönnyítő 
programozási nyelvre épül. A Unity 2D felületet első ránézésre szinte alig lehet megkülönböztetni 
a Unity 3D-től, egy-két effektustól eltekintve lényegében ugyanazt kapják a felhasználók. A Unity 
2D, köszönhetően a barátságos erőforrásigényének, akár a grafikus gyorsítást támogató, de kisebb 
teljesítményű gépek felhasználói számára is jó választás lehet. 

A Unity felület két főbb eleme a képernyő bal oldalán található indítópanel, valamint a képer- 
nyő tetején elhelyezkedő felső panel. A felhasználók az indítópanelen rögzíthetik leggyakrabban 
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3 A UNITY FELÉPÍTÉSE ÉS MŰKÖDÉSE 





használt alkalmazásaik ikonját, valamint ugyanitt jelennek meg az éppen futó alkalmazások is. A 
felső panelen érhető el az aktív alkalmazás menüje, a teljes képernyőre rakott ablakok ablakkezelő 
gombjai (bezárás, normál méret, minimalizálás), és a legfontosabb értesítések, köztük az üzenetek, 
a hálózati kapcsolatok, a hangerő, a naptár és a beállítások, valamint a kijelentkezésre és a rendszer 
leállítására szolgáló menü. 


A bal oldali indítópanelen látható Ubuntu ikonra kattintva érhetjük el a Dash elnevezésű felüle- 
tet, melynek segítségével alkalmazásokat indíthatunk el, kereshetünk korábbi dokumentumaink és 
a zenéink között. Ez a Scopes és Lenses elnevezésű megoldásra épül. A Scopes az egyes adatforrá- 
sok (például alkalmazások, fájlok, zenék) összefogására és rendszerezésére szolgál, míg a Lenses az 
ezek megjelenítésére szolgáló felületet. A Scopes mögött álló technológia lehetővé teszi például az 
értékelés (csak azokat az 5 csillagos alkalmazásokat szeretném látni,. . . ) és a kategóriák (. . . anelyek 


a Játék kategóriába tartoznak) szerinti szűrést. A megoldás mögött a Zeitgeist nevű motor működik. 
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A Zeitgeist mögött álló technológia a GNOME Activity Journal elnevezésű alkalmazással mu- 
tatkozott be. Sokan a mai napig az Activity Journallel azonosítják a Zeitgeistot, pedig valójában két 
különböző dologról van szó: a Zeitgeist egy eseményrögzítő motor, ami naplózza a különféle aktivi- 
tásainkat, míg az Activity Journal egyszerűen csak egy alkalmazás, amelynek segítségével megjele- 
níthetjük a naplózott eseményeket. A Zeitgeist nem fájlindexelő program, mint mondjuk a Tracker 
vagy a Beagle, csak a felhasználói aktivitást rögzíti. 


A Zeitgeist daemon folyamatosan fut a háttérben, és az egyes alkalmazások ennek segítségével 
tárolhatnak el információkat az adatbázisban, erre szolgálnak a dataproviders gyűjtőnévvel ellátott 
pluginek. A Rhythmbox és a Banshee már upstreamben tartalmazza a Zeitgeist támogatást, de létez- 
nek kiegészítők más alkalmazásokhoz is. A zeitgeist-datahub nevű Zeitgeist kiegészítő pedig azért 
felel, hogy a GtkRecentManager (Legutóbbi dokumentumok) adatai is bekerüljenek a Zeitgeist adat- 
bázisába. A Zeitgeist eredetileg Pythonben íródott, azonban a projekt fejlesztői 2011. november 3-án 
bejelentették, hogy az alkalmazást a 0.9- es kiadási ciklusban portolták Vala programozási nyelvre. 
Az új verzió API szinten kompatibilis a régivel, így nincs szükség a már meglévő alkalmazások 
módosítására. A portolás eredményeként jelentősen csökkent az alkalmazás elindulási ideje és erő- 
forrásigénye 15. 
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4. А Unity és a felhasználók 


Az Ubuntu mögött álló vállalat, a Canonical több tesztet is végzett ellenőrzött körülmények között 
laikus felhasználókkal, és az így szerzett tapasztalatokat és visszajelzéseket is felhasználták a fe- 
lület kialakítása során. Az első tesztelésre 2010 októberében került sor, a Unity Ubuntu 10.10-be 
került változata alapján, majd 2011 áprilisában megismételték a tesztet, immáron a Unity legújabb, 
Compizra épülő változatával, a harmadik tesztelésre pedig az Ubuntu 11.10 megjelenésekor, 2011 
októberében került sor. Az így szerzett visszacsatolás fontos szerepet játszott a felület kialakításában. 

Mint az a fentiekből kiderül, a Unity fejlesztők nagy hangsúlyt fektettek arra, hogy kiszolgálják 
azon felhasználók igényeit, akik korábban nem használtak GNU/ Linux desktopot, és vonzó alter- 
natívát kínáljanak számukra. Az ígéretek szerint a következő fejlesztési ciklusban a tapasztalt, profi 
felhasználók (power userek) igényei is nagy figyelmet kapnak . A cél az, hogy a tervek szerint 2012 
áprilisában megjelenő Ubuntu 12.04 LTS már az ő elvárásaiknak is maximálisan meg tudjon felelni. 
Ez azért különösen fontos, mert az Ubuntu jelenlegi aktív felhasználói bázisának igen jelentős részét 
alkotják ezek a felhasználók. A másik fontos cél az Ubuntu 12.04 LIS kiadásában a stabilitás és a 
teljesítmény további javítása. Emellett nagy hangsúlyt fektetnek majd az akadálymentesítésre és a 
több monitoros rendszerek támogatására 15. 


5. А jövő 


Az Ubuntu 12.04 LTS megjelenését követően újabb terület meghódítására készül az Ubuntu. Mark 
Shuttleworth, az Ubuntu alapítója az Ubuntu fejlesztők 2011 novemberében megrendezett konfe- 
renciáján (Ubuntu Developer Summit) bejelentette, hogy a disztribúció két éven belül a klasszikus 
számítógépek mellett okostelefonokon, táblagépeken és televíziókon is elérhető lesz. Az Ubuntut fut- 
tató okostelefonokra még várnunk kell egy kicsit: a fejlesztők az Ubuntu 12.04 LTS megjelenéséig 
arra fognak összpontosítani, hogy a rendszer a lehető legstabilabb legyen, és a Unity felületet tovább 
finomítsák, hogy egyaránt megfeleljen az otthoni felhasználók és a vállalati szféra igényeinek. Ezt 
követően helyeződik át a fókusz az újabb eszközök támogatására. 
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Mark Shuttleworth az UDS nyitóelőadásában kiemelte, hogy a világ átalakulóban van: egyre 
több intelligens eszköz jelenik meg, amelyek alkalmasak komoly, teljes értékű operációs rendszer 
futtatására, és képesek egymással és a clouddal kommunikálni. A Unity felület kifejlesztésével az 
Ubuntu egyik célja az volt, hogy a felhasználók számára egységes élményt nyújthasson a legkü- 
lönbözőbb eszközökön. A tervek szerint a Unity lehetővé teszi majd, hogy ugyanazt a felületet 
használjuk a telefonunkon, a táblagépünkön, az autónkban, a tévénken és persze a számítógépün- 
kön. A Unity rugalmasan alkalmazkodni fog az egyes eszközök adottságaihoz, és bárhol megállja 
majd a helyét. Ennek gyakorlati megvalósítása komoly feladatot jelent, hiszen nyilvánvalóan telje- 
sen másképp használunk egy asztali számítógépet, mint egy, a zsebünkben is kényelmesen elférő 
okostelefont vagy egy nagyképernyős televíziót. 

A Unity felületet eleve úgy tervezték meg, hogy a későbbiekben támogassa az érintőképernyős 
eszközöket is. A multi-touch, vagyis a több ujjas érintés támogatása az Ubuntu 10.10 Netbook Edi- 
tion megjelenésekor már része volt a rendszernek, tehát az alapok már most is megtalálhatók a 
Unityben. Ahhoz azonban, hogy a rendszer jól működjön az olyan eszközökön, mint a táblagépek 
vagy az okostelefonok, nagyon sok tennivaló van a felület kialakítása tekintetében. Ez nem csak 
magát a Unityt érinti, hanem az alkalmazásokat is, amelyeket úgy kell módosítani, hogy azokon 
az eszközökön is használhatók legyenek, amelyek nem rendelkeznek egérrel és billentyűzettel. Az 
egyik legnyilvánvalóbb példaként említhetőek a menük, amelyek remekül használhatók egérrel, érin- 
tőképernyőn azonban nagyon kényelmetlen lenne a használatuk. Vagyis nem elég magát a Unityt 
továbbfejleszteni, az alapvető alkalmazások felületét is alkalmassá kell tenni a táblagépeken és okos- 
telefonokon való használathoz. 

Nem csak a felszínen jól látható területeken van szükség fejlesztésre. Míg a klasszikus számító- 
gépek tipikusan az x86 architektúrára épülnek, addig az új eszközök esetében (táblagépek, okoste- 
lefonok, okostévék) az alacsony fogyasztású, de egyre nagyobb teljesítményű ARM architektúra a 
meghatározó. Ezért különösen fontos, hogy az Ubuntu magas szinten támogassa ezt az architektúrát 
15. Ebben kulcsszerepe van a Linaro projektnek, melynek célja, hogy a nyílt forrású ARM fejlesz- 
tések számára hátteret és eszközöket biztosítsanak. A Linaro fejlesztők szorosan együttműködnek 
az Ubuntu fejlesztőkkel, ezt jelzi az is, hogy a Linaro fejlesztők találkozója, a Linaro Connect egy 
időben és egy helyszínen van az Ubuntu fejlesztők találkozójával, így az érdeklődők részt vehetnek 
egymás megbeszélésein, ezzel is segítve a két fél együttműködését. 

A Canonical a Linaro mellett hardvergyártókkal is együttműködik, hogy az Ubuntu megjelen- 
hessen a különböző mobil eszközökön. Mark Shuttleworth azt ígérte egy, a ZDNet által készített 
interjúban, hogy a fejlesztések eredményeit nyílttá teszik, és azok folyamatosan bekerülnek a stan- 
dard Ubuntuba. A tervek szerint az Ubuntu 2014-ben megjelenő LTS kiadása már eszközök széles 
skáláját fogja támogatni. Ezt követően várható a különböző Ubuntus mobil készülékek széles körű 
megjelenése is. 


6. Ne féljünk az újdonságoktól! 


A 2011-es Szabad Szoftver Konferencia kiadványának olvasói között vélhetően jelentős számban 
vannak azok, akik nem csak használni akarják a számítógépüket, hanem szívesen elmélyednek 
a technikai érdekességek és új fejlesztések világában is. Azok, akik nem csak olvasni szeretné- 
nek a fejlesztés alatt álló Ubuntu kiadás újdonságairól, hanem maguk is szívesen kipróbálnák, a 
http://cdimages.ubuntu.com/daily-live/current/ címről közvetlenül letölthetik a fejlesztői változat 
legfrissebb napi buildjét. Ez, mint minden fejlesztői kiadás, természetesen nem alkalmas éles felhasz- 
nálásra, hiszen nem stabil rendszerről van szó. Ugyanakkor arra tökéletesen megfelelő, hogy akár 
egy virtuális gépben futtatva, akár egy pendrive-ról elindítva teszteljük, hol tart éppen az Ubuntu 
fejlesztés alatt álló kiadása. 
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Amennyiben а tesztelés során esetleg belefutnánk valamilyen hibába, azt а Canonical fejlesztői 
portálján, a Launchpadon (https://launchpad.net) jelenthetjük. A hibajelentéssel kapcsolatos infor- 
mációk a https://wiki.ubuntu. com/Bugs/ és a https://help.launchpad.net/Bugs oldalakon olvashatók. 
Fontos, hogy mielőtt bármilyen bugot jelentenénk, győződjünk meg arról, korábban nem jelentette-e 
már azt valaki. Ha igen, akkor nézzük meg, hogy ki tudjuk-e egészíteni azt további információk- 
kal, ezzel segítve a probléma gyors megoldását. Ha esetleg bizonytalanok vagyunk, hogy milyen 
információkat kell beleírnunk a bugreportba, bátran kérjünk segítséget IRC-n, a Freenode hálózat 
#ubuntu-bugs csatornáján vagy az adott projekt saját IRC csatornáján. 

Az Ubuntu óriási utat tett meg azóta, hogy 2004 őszén megjelent az első kiadása. Az igazán 
izgalmas szakasz azonban még előttünk áll: ha minden a tervek szerint alakul, a kis, Debian alapú 
GNU/Linux disztribúció eljuthat oda, hogy asztali számítógépeken, notebookokon, netbookokon, 
táblagépeken, okostelefonokon, okostévéken, kis vállalati szervereken és gigantikus cloud kiszolgá- 
lókon egyaránt megállja a helyét. Az előttünk álló két év különösen izgalmasnak ígérkezik, érdemes 
lesz tehát folyamatosan nyomon követni a rendszer fejlődésével kapcsolatos híreket, és időről időre 
kipróbálni az éppen aktuális fejlesztői változatot. 
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КТЕ támogatás a LibreOffice Writer programban 


Vajna Miklós cvmiklos @frugalware.org> 


Kivonat 


A LibreOffice RTF import és export támogatása igen elavult volt és a karbantartása nehézkessé 
vált. A cikkben bemutatom az új КТЕ importert (tokenizálót) és exportert, mely nem csak a ké- 
sőbbi fejlesztést teszi könnyebbé a gondos tervezésnek köszönhetően, de már most is számos 
többlet-támogatást nyújt az eredeti RTF filterekhez képest. A cikkben bemutatott új funkciókat a 


LibreOffice 3.5 már tartalmazni fogja minden RTF fájl olvasásához és írásához. 
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2 A LIBREOFFICE FEJLESZTÉSRŐL 





1. A Google Summer of Code-ról 


A GSoC egy pályázati lehetőség szervezetek és tanulók számára. Először szervezetek pályázhatnak 
ötletekkel, majd mikor az elfogadott szervezetek listája publikussá válik, tanulók jelentkezhetnek 
a szervezeteknél. Jelentkezéskor általában egy — a szervezet által kiírt — ötlet alapján kidolgozott 
pályázattal kopognak be a tanulók, de a kreatívabbak teljesen saját ötlettel is előállhatnak. Mikor 
lezárult a jelentkezési határidő, a pályázatok elbírálásra kerülnek, végül publikussá válik a sikeresen 
beválasztott tanulók listája. 

A program móttója — Flip Bits not Burgers — arra utal, hogy eredetileg a cég ezzel azokat a tehet- 
séges fiatalokat kívánta megcélozni, akik egyébként gyorséttermekben töltötték volna a nyarat, hogy 
pénzhez jussanak. A kezdeményezés lehetőséget biztosít arra, hogy szabad szoftver fejlesztéssel jus- 
sanak pénzhez. 

A GSoC két ok miatt kerül említésre az előadáson: 


e a bemutatott КТЕ filterek is hasonló finanszírozásban készültek el; 


e reklámkéntis szolgál, hogy jövőre is legyenek olyan tanulók, akik a LibreOffice fejlesztésével 
szeretnék tölteni nyarukat. 


2. А LibreOffice fejlesztésről 


A LibreOffice projekt 2010. szeptember 28-án indult, alapítványi hátterét a The Document Founda- 
tion (röviden TDF) biztosítja. A szabad szoftveres projekt az OpenOffice.org forkjaként látta meg a 
napvilágot, a korábban patchset formájában létező Go-OO folytatásaként. 

Fontos különbség, hogy míg a Go-OO a funkciók nagy részét hosszútávon vissza akarta juttatni 
az OpenOffice.org-ba, addig a LibreOffice esetén ezt feladták, így a projekt már a saját útján jár. 

Ettől eltekintve persze a nagy kódbázis jelentős része megegyezik, így az OpenOffice.org pro- 
jektben szerzett tapasztalatok itt is könnyen kamatoztathatóak. 

Gyakori félreértés, hogy az emberek úgy gondolják: a LibreOffice Java nyelven íródott, holott 
ez nincs így. A kód nagy része C++, a maradék többségét valóban a Java teszi ki, de emellett még 
számos egyéb nyelven írt kisebb kódokat is tartalmaz a projekt (XML, Make, ASM, Yacc, Perl, 
Python stb.). 

Kedvcsinálóként az előadáson ismertetésre kerülnek azok az első lépések, melyeket meg kell 
tennie azon önkénteseknek, akik szeretnének a projekthez programkóddal hozzájárulni. 


Első build 


Az első fordítás három lépésből áll: 


1. forrás letöltése: 
git clone git://anongit.freedesktop.org/libreoffice/core 
2. fordítás 


./autogen.sh 
make 
make dev-install 
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3. futtatás 


cd install/program 
source ./ooenv 
./soffice.bin 


Inkrementális build 


Mivel egy teljes fordítás sok időt vesz igénybe, a következő kérdés, hogy a forráskódbeli módosítás- 
tól az új futtatható programig hogyan juthatunk el. Ennek módja, hogy a forráskód számos (jelenleg 
226) modulra van osztva, melyek külön-külön is fordíthatóak. 

Példáulhaawriterfilter modult módosítottuk, akkor lépjünk annak könyvtárába és futtas- 
suk ott a make programot, aminek határására futtatáskor már életbe lépnek a változtatásaink. 

A gyakorlatban néhány paramétert praktikus alkalmazni: 


e —5: kevesebb kimenet kérése, hogy a hibákat, figyelmeztetéseket könnyebben észrevegyük; 
e —r: а beépített implicit szabályok elhagyása, mely gyorsabb működést eredményez; 


e -j4: többszálú fordítás (a 4 az aktuális gépen elérhető CPU-k vagy magok számával helyette- 
sítendő); 





e dbglevel=2: a fejlesztést segítő, OSL TRACE () kimenetek bekapcsolása; 
e build: csak fordítás, unit tesztek futtatásának elhagyása. 
A teljes parancs tehát: 

make -sr -j4 dbglevel=2 build 


Aminek segítségével tipikusan tíz másodperc alá szorítható a fordítási idő. Természetesen az 
egyes paramétereket mindenki ízlése szerint megválaszthatja. 


A projekt mérete 


A LibreOffice az egyik legnagyobb méretű szabad szoftveres projekt. Voltak arra törekvések, hogy 
a forráskódot húsznál is több különálló tárolóba szétválasszák, de jelenleg olyan szoros az ezek 
közötti függés, hogy ez kudarcot vallott: a fejlesztés során nem vált lehetségessé ténylegesen csak 
egy-egy alrendszer módosítása. Ennek következtében jelenleg a módosítások nagy része egyetlen 
(az ún. core) tárolóban történik. 

A git clone végeztével kb. 8 millió kódsorhoz jutunk, a merevlemezünkön pedig kb. 4 GB 
helyet veszítünk. A teljes fordítás ideje eltérő lehet: Linuxon szélső értékként egyrészt a gyakori 
fordítás (pl. tinderbox) és ccache használat mellett elérhető kb. 15 perces időigényt lehet említeni, 
a másik véglet ha minden nyelv támogatását bekapcsoljuk, akkor még egy négymagos gépen is 3—4 
óra fordítási idővel kell számoljunk. ! 





lHa lassúsági rekordot szeretnénk elérni, próbálkozzunk a fordítással egy manapság oly divatos netbookon. 
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3 RTF EXPORT FEJLESZTÉS 





Kollaboráció 


A LibreOffice fejlesztése főként a következő kommunikációs csatornákon keresztül folyik: 
e forráskód-kezelés: git; 
e napi kommunikáció: IRC, e-mail; 


e stratégiai döntések: Technical Steering Call (Т$С). 


КТЕ filterek 


Filtereknek nevezzük azokat а programmodulokat, melyek а dokumentummodell betöltését vagy el- 
mentését végzik valamilyen — lehetőleg szabványosított — formába. A cikk szerzője a továbbiakban a 
LibreOffice Writer alkalmazás RTF import/export filtereinek elkészítése során szerzett tapasztalatait, 
illetve élményeit ismerteti. 

Az RIF formátumot sokan jelentéktelen szabványnak tartják, pedig a maga nemében egyedül- 
álló: 


e Az első verzióját 1987-ben fogadták el, megelőzve az XML-t vagy az ODF-et; 


e Az újabb verziói visszafele kompatibilisak; 


ze 


e Időről időre frissül, a jelenlegi (1.9.1-es) szabvány támogatja a beágyazott táblázatokat, OLE 
objektumokat stb. ; 


e Előszeretettel használják sok helyen (pl. kormányzati űrlapok), ahol az ODF még túlságosan 
újdonságnak számít. 


Természetesen megvan az a hátránya, hogy az RIF nem egy nyílt szabvány, hanem a Microsoft 
adja ki az újabb verziókat. 


3. ЕТЕ export fejlesztés 


2010 nyarán egy teljesen új RTF exporter készült el. Az ötlet az volt, hogy az RTF sok aspektusban 
hasonlít a doc, illetve docx formátumokra (mindhárom Microsoft találmány), és a doc/docx expor- 
tereknek már van egy közös alapja. A korábban különálló RTF exporter helyett tehát egy — erre a 
közös alapra építkező — új RTF exporter készült el. 

A szokásos célok (ne okozzon regressziót a régi filterhez képest, legyen kisebb, nyújtson több 
funkcionalitást) közül csak a méret csökkentése nem sikerült, az új funkciók helyigénye miatt. 

Ez az exporter először a Go-OO 3.3 első teszt-kiadásában volt elérhető, azóta része a LibreOffice- 
nak. A LibreOffice megszületése előtt része lett az OpenOffice.org 3.4 bétának is, amiből sajnos 
azóta se látott a világ stabil kiadást." Ettől függetlenül az Oracle híresen szőrszálhasogató ОА-ёп 
átjutott az exporter, és ennek során számos hasznos visszajelzést kaptam a cég mérnökeitől. 

Az exportert leginkább azoknak érdemes kipróbálniuk akiknek problémájuk akadt a régi válto- 


Жол 


zattal, de az érdeklődők számára az előadáson példákat mutattam a következő új funkciókra: 


e könyvjelzőkre mutató oldalszám-hivatkozások; 


e karakter tulajdonságok (kiterjesztett térköz, alávágás); 





? Aki kíváncsi a fejleményekre, látogasson el az Apache OpenOffice.org (incubating) projekt fejlesztői listájára és kövesse 
az eseményeket. 
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e OLE objektumok (pl. diagram); 

e rajzok; 

e űrlapok; 

e sorszámozás; 

e matematikai kifejezések, szerkesztést lehetővé tevő natív adattal; 
e oldaltörések; 

e oldalszámozási stílusok, oldalszámozás újraindítása; 
e képek Wordpadben; 

e post-it mező; 

e hasábtörés; 

e védett szakaszok; 


e beágyazott táblázatok; 


e javított tartalomjegyzék. 


Az új funkciók hosszú listája ellenére az új filter sem hibamentes, visszajelzéseket a Freedesktop 
Bugzillájába? kéretik eljuttatni. 


4. RTF import fejlesztés 


Idén nyáron került sor az új КТЕ importer elkészítésére, mely az exporterhez hasonló ötleten alapszik: 
a docx importerhez készült framework újrahasznosítható lenne több tokenizáló elkészítéséhez az 1. 
ábrán látható módon. 


Jó példa az így egy helyen megvalósított funkciókra a mezők értelmezése (pl. oldalszám, anno- 
tációk) vagy a Writer oldalstílusai és a Word speciális fejlécei között. 


Tesztelés 


A tesztelés első lépése a csak a tokenizert tesztelő unit teszt elkészítése volt. A minden fordítás során 
automatikusan lefutó ellenőrzés a korábbi RTF importer CVE hibáihoz tartozó teszt dokumentumo- 
kat értelmezi. Mivel csak a tokenizer kerül tesztelésre, a teljes futás kb. 200 ms. 

A megoldás szépsége, hogy így már akkor lehetséges a teszteket végrehajtani, mikor a Writer 
alkalmazást megvalósító sw modul még nem került lefordításra. 

Természetesen ez a teszt a kézi ellenőrzést nem helyettesíti, hiszen a vizuális megjelenést nem 
vizsgálja — csak azt, hogy a tokenizer elfogadja, vagy elutasítja az adott dokumentumot. 





3http://bugs.freedesktop.org 
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4 RTF IMPORT FEJLESZTÉS 





File system storage 


RTF document DOC document DOCX document 
| | | 
v v v 

RTF tokenizer DOC tokenizer DOCX tokenizer 


И 


Domain mapper 


И 


Writer UNO АРІ 


и 


Writer document 


writerfilter module 


sw module 


1. ábra. Az КТЕ import filter architektúrája 


Új funkciók 
Az export filterhez hasonlóan az importer új funkcióiból is ízelítőt kapnak az előadás hallgatói. Be- 


mutatásra kerülnek a korábban nem, vagy hiányosan, illetve rosszul támogatott következő elemek 
importálása: 


e beágyazott táblázatok; 
e lábjegyzetek; 

e post-it mezők; 

e űrlapok; 

e rajzok; 


e szövegdobozok. 


Hatás a DOCX importra 


A régi RTF importernek néhány funkcióját először azért nem lehetett megvalósítani az új filterben, 
mert a keretrendszer nem támogatta az adott funkciót. Ezek a módosítások a bekerülésük után a 
DOCX importert is javították, melyből néhány szintén demonstrálásra került az előadáson: 


e dupla-áthúzás; 


e lábjegyzetek újraszámozása. 
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5.  Elérhetőségek 


A szerző ezúton is elnézést kér, hogy sok — a cikkben szereplő — témát csak érintőlegesen említett, 
csak az import és export filterek témáról vastag könyvet lehetne írni, a cél leginkább a figyelemfel- 
keltés volt. Az alábbi linkek további kérdések esetén remélhetőleg segítséget nyújtanak. 


e LibreOffice honlap: http://libreoffice.org/ 
e GSoC: http://code.google.com/soc/ 
e A diák és ezen cikk elérhetősége: http://vmiklos.hu/odp/ 
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1 MIK AZOK A SZÁLAK? 





1. Mik azok a szálak? 


A szálak hasonló egységek mint a folyamatok (processzek), ám néhány erőforrást nem közvetlenül 
a kerneltől kapnak hanem a meglévő folyamaton belül osztoznak rajtuk egymás közt. Magyarul a 
szálak azok egy folyamaton belüli alfolyamatok, melyek a meglévő folyamat erőforrásait használják 
megosztva. 













































































Folyamat (process) Folyamat (process) 
i-ik folyamat i+1-ik folyamat 
Memória Memória 
Fájlok (pl. leírók) Fájlok (pl. leírók) 
Egyéb erőforrások Egyéb erőforrások 
Kernel 











1. ábra. A kernel és a folyamatok 


A folyamaton belül a szálak a folyamat összes erőforrását közösen használják, egyedül a szálan- 
kénti saját stack az, amivel kizárólagosan gazdálkodhatnak. Természetesen ez azonnal mutat egy ké- 
zenfekvő problémát, a globális adatterületekhez minden szálnak szabad hozzáférése van, így egymás 
, feje fölött" átnyúlkálva keresztbe is módosíthatják azokat, amik reprodukálhatatlan összeomláshoz 
vezethetnek. Természetesen ennek a problémakörnek nagyon körbejárt feloldása van, ez később ke- 
rül ismertetésre. 
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2. ábra. A folyamat és a szálak 


1.1. Mikor használunk szálakat? 


Nyugodtan kijelenthetjük, hogy a programok több mint 90%-а egyáltalán nem igényel szálkezelést. 
Szálkezelésre az alábbi szempontok alapján tekinthetjük alanynak a kódot: 


e Független a többi kódtól. Ezalatt például értsük azt, hogy a kód igényel-e adatokat más kód- 
részletektől illetve az eredményeitől függenek-e más kódrészletek. 


e Hosszú ideig blokkolja a futást valamely művelete. Gyakori eset valamely lassú kommuniká- 
ciós interface használata, pl. RS232. 


e Hosszú futásidejű, a CPU-t terhelő műveletet végez-e? Ez szintén blokkolja pl. az IO művele- 
teket egy folyamaton (processzen) belül. 
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1.2 LinuxThreads vs. Posix 





e Aszinkron műveleteket végez a kód, pl. hálózati kommunkikáció. 


e Kevésbé fontos (alacsonyabb prioritású) műveletet végez a kód. 


A felsorolásból látható, hogy a potenciális szálhasználó programok elsősorban a szerver prog- 
ramok, webszerver, printszerver, adatbázis kiszolgálók. Folyamatosan aszinkron eseményekre vála- 
szolnak, majd IO műveleteket végeznek. Hasonló feladatok vannak a méréstechnikában, jellemzően 
több, lassabb perifériát, adatgyűjtőt kell kiszolgálni. 

Amennyiben valóban multiprocesszoros gépre fejlesztünk és a rendszer szálkezelése a szálakat 
el is tudja osztani az egyes processzorok közt, úgy a jelfeldolgozás (pl. kép-, videofeldolgozás) is 
komolyan gyorsulhat a párhuzamosítható részek valódi párhuzamosításával. Alap példának a mát- 
TIX szorzást vagy a Mandelbrot-halmazok számítását szokták felhozni, ám tudni kell, hogy egypro- 
cesszoros gépen a többszálas implementáció még lassulást is előidéz, mivel az egyes feladatok közti 
váltást adminisztrálni kell és a futás valójában nem párhuzamos, csak annak tűnik. 


1.2. LinuxThreads vs. Posix 


A Linuxban 1996-ban jelent meg a szálkezelés, formailag majdnem POSIX konform módon, azon- 
ban megvalósításában attól eltérően. A gondot az okozta, hogy a 2.4- es verzióig a kernel nem volt 
felkészítve a szálak kezelésére. A szálakat mint önálló kernel szálakat kezelte, s ez olyan következ- 
ményekkel járt, amik a többszálú programok használatában okoztak sok gubancot. Mik voltak ezek 
a problémás pontok? 


e Külön PID-je volt minden egyes szálnak. 


e Ве kellett vezetni egy manager thread-et, amely valójában kezelte az összes többit, pl. a létr- 
hozásuk is ezen keresztül ment. Ez egyrészt szűk keresztmetszet volt, másrészt viszont ha ez 
a szál megszűnt (pl. ki11), akkor a többit kézzel kellett egyenként kilőni. Ez több száz szál 
esetén komoly problémát jelentett. 


e A jelek (signal) kezelése rendszeresen bedöntötte a programot, abszolút nem volt köze а 
jelkezelésnek a POSIX előírásokhoz. 


A jelkezelés problémáinak folyományaképp a SIGSTOP és a SIGCONT csak az adott szál 
futását állította le. 


e Az ТА-32 architektúrán 8192 szál volt a maximum. Ez nagyobb projekteknél (pl. webszerver) 
komoly korlátot jelentett. 


e A rengeteg PID a /proc táblát használhatatlanná tette. 


Ezen problémák nagyon hamar komoly korlátokat jelentettek a többszálú programozásban, így 
a munkák rövidesen megkezdődtek, melyek a POSIX kompatibilis pthred implementáció megírá- 
sához vezettek. A fontos szempontok a tervezésnél az alábbiak voltak: 


e POSIX megfelelőség. Forráskód szinten kompatibilis legyen más POSIX rendszerekkel. 

e А többprocesszoros rendszerek erőforrásainak tényleges kihasználása. 

e , Olcsó", azaz gyors és hatékony szál indítás. 

e Azon programokat, melyek a pthred libraryval linkelve vannak, ez ne terhelje akkor sem, ha 


nem használnak szálakat. 
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2 A SZÁLAK KEZELÉSE 





e Bináris kompatibilitás a LinuxThreads implementációval. 


e Jó skálázhatóság. Többprocesszoros rendszerekben ez legyen közel lineáris, az adminisztrá- 
ciós igény komolyabb növekedése nélkül. 


e A szoftveres limitek megszüntetése, pl. a szálak lehetséges száma. 


e A nagygépes architekúrák támogatása. A nagygépes processzorok sokszor jelentősen külön- 
böznek a desktop gépektől, ezeken is megfelelően kell menniük a szálaknak. 


e NUMA support, a non-uniform memory architectures támogatása. 

e C++ integráció 

Ezek a munkák 2002-ben tetőztek és eredményeképp létrejött a pthread library és a hozzá tartozó 
kernel támogatás is. 
2. А szálak kezelése 


A szálak kezelésével kapcsolatban három fő csoportba oszthatjuk az ezen feladatokhoz tartozó függ- 
vényeket: 


e A szálak menedzselése: paraméterezés, létrehozás, csatolás. 


A mutexek: ezek használata biztosítja azt, hogy egy adatterülethez konkurens szálak úgy férje- 
nek hozzá, hogy egymás tevékenységét ne üssék ellenőrizetlenül keresztbe. Ezek olyan szoft- 
veres zárak, melyek biztosítják ezt, hogy egy adathoz egyszerre csak egy szál férhet hozzá, a 
többi addig várakozik. 


Feltételes változók: míg a mutexek az adat hozzáférése alapján működnek, a feltételes válto- 
zók az adat értéke alapján teszik lehetővé egyes kódrészletek lefutását. Ez egyúttal a szálak 
közti kommunikációt is magában foglalja. 


2.1. Nevezéktan 








pthread _ A szálkezelő függvények nevének kezdete. 
pthread attr Szál attribútum függvények. 

pthread mutex Mutex függvények. 
pthread_mutexattr_ Mutex attribútum függvények. 
pthread сопа Feltételes változók. 

pthread condattr Feltételes változók attribútumai. 
pthread key Szálspecifikus kulcsok. 


2.2. Szálak a gyakorlatban 


Egy , csontváz" mintaprogram, melyen az alapelvek vázlata tanulmányozható. Van két függvényünk, 
ado 1() ésado 2 (), melyek csinálnak valamit egy közös, globális változón (jelesül inkremen- 
tálják és kiírják az értékét), eközben biztosítják azt, hogy egymás feje fölött ne nyúlkáljanak át. 
Amennyiben futtatjuk eme programot, úgy egyesével növekvő számokat ír ki, melyekről látható 
lesz, hogy éppen melyik szálban történt a rajtuk végzett művelet. 
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2.2 Szálak a gyakorlatban 





#include <stdio.h> 
#include <pthread.h> 


void do_1 (void); 
void do_2 (void); 


int my_val = 0; 
pthread_mutex_t my mutex-PTHREAD MUTEX INITIALIZER; 

















int main (int argc, char xxargv) { 


pthread і threadi, thread2; 

pthread attr t custom sched attr; 
pthread_attr_init (&custom_sched_attr); 
pthread_attr_setscope (&custom_sched_attr, \ 














PTHREAD SCOPE SYSTEM); 





pthread_create (&threadl, &custom_sched_attr, \ 
(уоіа х) ао 1, МО); 
ріһгеаа сгеаіе (&Еһгеаа2, &custom_sched_attr, \ 
(void х) ао 2, NULL); 











hread јоіп (&һгеаа1, NULL 
hread јоіп (&һгеаа2, NULL 


`~ 





EN E: 





`~ 





while (1) {}; 
return 0; 





void do 1() 
{ 


pthread_mutex_lock (&my_mutex); 
printf ("Thread 1: %d\n", my_val++); 
pthread_mutex_unlock (&my_mutex); 


void do_2() 
{ 


pthread_mutex_lock (&my_mutex); 
printf ("Thread 2: %d\n", my_val++); 
pthread_mutex_unlock (&my_mutex); 
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2 A SZÁLAK KEZELÉSE 





2.3. Más rendszerek 


A szálkezelés területén egy fix pontunk van amelyen keresztül be tudjuk sorolni a különféle rend- 
szereket: POSIX alapú az adott implementáció vagy sem. A UNIX alapú rendszerek mindegyikéről 
elmondható, hogy a POSIX-hoz igazodnak, természetesen különbözőségek vannak, egyrészt hogy 
implementáltak-e mindent ami a POSIX szabványban van, illetve milyen plusz dolgokat nyújtanak 
még ezen felül. Forrás szinten jellemzően kompatibilisek — vagy minimális munkát igényelnek — 
ezeken a rendszereken a szálkezelést használó programok. Az Ablax világa egy teljesen más világ, a 
Win32 illetve az OS2 (majd NT) típusú szálkezelés alapjaiban különbözik az eddigiektől, a POSIX- 
ra leképezni sem lehet, ám ennek ellenére készül(t) POSIX megfelelőségű réteg ezen rendszerekre, 
erről mélyebb információim nincsenek, érzésem szerint a „meg tudjuk csinálni ezt is, mert olyan jók 
vagyunk" világmegváltási elv okán készülhetett el. 
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